Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

With my limited knowledge of HTTPS I started wondering: How do proxy servers filter HTTPS websites? I mean adding a proxy server is essentially a MITM attack which is what HTTPS was explicitly supposed to prevent

The only way I can think of is to block the server by IP and port. However with things like SNI and wildcard certificates this means that you could block legitimate content (assume that a site that must be blocked shares an IP with a site that must be available in this situation).

What does it do then? You can't read the content of the connection since its encrypted; all you know is that someone is most likely sending an HTTPS request to some IP address.

share|improve this question
up vote 4 down vote accepted

How do proxy servers filter HTTPS websites?

It isn't very easy. You have a couple poor choices, each with there own problems.

You can do it purely on the NAME/IP passed via the HTTP CONNECT request. Meaning you are likely to have lots of false positives/negatives.

You can perform a MITM attact. With a couple products in a corporate environment, a CA is setup, and must be trusted by the clients, and the proxy server creates certificates as needed so the client believes everything is fine. The proxy must validate the certificates of the sites the user connects to. This will also mean that if a site doesn't have a valid SSL cert, then it would probably be completely impossible for a client to continue to the site. I suspect you would also have a larger chance of legal issues if you did this.

There is also the possibility of running a filter on the client machine, but unless the client machine is really locked down, this probably wouldn't work to well.

However with things like SNI and wildcard certificates this means that you could block legitimate content

If you really need to filter SSL, you almost certainly need to do it as a whitelist, and not a blacklist. So you permit sites you trust, and block bad sites.

share|improve this answer
Wow, I never knew corporate proxy servers did that. Thats impressive and scary at the same time. – TheLQ Jun 2 '11 at 23:50

The browser knows it's connecting to a proxy, it's not really "fooled". There are passive proxies that you can setup, but still the browser will know that proxy is there the first time it hits an encrypted URL if the proxy doesn't just route the traffic through untouched. Often the connection to the proxy server is either always encrypted or always unencrypted, whichever the proxy and browser are configured for.

If you mean reverse proxy, where the proxy acts as the target server and proxies (usually for performance, failover, or load balancing features) to a backend server; the proxy has to be specially configured with the SSL information to be able to fool the browser. This information will be specific for the destination, it can't just impersonate any destination server. With these as well, the connection between the backend server and proxy, and the connection between the browser and client might each be encrypted, but not necessarily, and they aren't necessarily dependent on the other (though some proxies can be configured to be so).

In either case the proxy has to be configured either by your network, or the destination network. The proxy will be aware of the content being passed through, but there is no third party involved, just extensions to the original two parties.

share|improve this answer
Sorry, I was really just interested in normal proxy's (eg corporate proxys), not reverse proxys. And if the connection to the proxy is unencrypted, where does the destinations certificate come into play? – TheLQ Jun 2 '11 at 22:01
We run MS FF TMG Server (proxy), when a client requests an https site, the proxy makes its own connection to the target server, checks the certificate details, retrieves the page and other components, then returns all this to the client. We don't use an encrypted connection between client and server because it would add unnecessary overhead, the client-to-proxy traffic is all unicast and our network is fully switched (so one computer can't snoop on another computers traffic). – Chris S Jun 3 '11 at 1:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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