I have a DNS server that resolves all traffic to my Squid server that will proxy all HTTP traffic transparently (it must be transparent or it will drop a invalid url error) which works great.

The problem lies with HTTPS. My goal is to make a HTTPS work completely normally with my interception (I don't want to use fake ceritifcates and have the message of "do you want to continue" error), I've tried many way to make this happen with complete failures. I don't even want to touch the HTTPS data but I have to because all domains resolve to my server.

  1. I've tried using IPTables to redirect the HTTPS traffic to their server directly which is completely impossible because you cannot read the hostname with IPtables and you cannot redirect them dynamically.
  2. I have tried using Haproxy to just pass along the data, which works great but it requires me to put in each server individually, so unless I was to make a config file that is millions and millions of lines longs of just website domains/subdomains I cannot use it.

I can understand not wanting to perform interdiction of HTTPS traffic, both for the UX reasons and for reducing exposure to liability for the contents of decrypted communications.

Instead of having DNS resolve to your web proxy, have it resolve normally to the true address (set your DNS servers as caching, recursive resolvers). Using either WCCP or DNAT on the router at the edge of your user community (probably one or more ABRs, presuming you have a separate area for client devices).

Rules might be:

  • destination port is TCP80 or TCP8080
    • source is not proxy-server, destination is not proxy-server, DNAT to proxy-server:3128, log
    • source is proxy-server, pass unchanged (log on the proxy-server)
  • destination port is TCP443 or TCP 8443
    • pass unchanged, log

Hope that helps

  • WCCP would allow you to do essentially the same thing, plus your router could learn about availability of hte proxy-server, and pull out the DNAT rule if the proxy-server was not reachable. – DTK Sep 29 '14 at 6:43
  • One other thing to help guide your solution, if the UX concern is the primary reason to avoid HTTPS interdiction (as opposed to policy or legal/tort exposure), you could issue a certificate with basic constraints "CA: True" and add it to your clients as a trust-anchor (via GP for Windows or Puppet/CFEngine for Linux/UNIX). This would give you the interdiction capabilities if needed as part of DLP strategy. If you do this, please understand the risk, and store the key-pair for the proxy-server in an HSM or token. – DTK Sep 29 '14 at 6:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.