Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

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

My workplace uses a proxy to connect to the internet, even for https sites.

It was my understanding that for this to work, the proxy would be considered a MITM, and the certificate presented would be from the proxy.

This root for this certificate would need to be trusted, which would be easy to achieve via group policy in a corporate environment.

However, this is not what I'm seeing.

I'm seeing the genuine cert chains from the target website, but wireshark is showing that I only ever hit my proxy.

What gives?

share|improve this question
up vote 10 down vote accepted

Since version 1.1, HTTP supports a special method, CONNECT. This sets up the TLS tunnel through the proxy, even though your computer only directly connects to the proxy. HTTPS knows how to tunnel the TLS handshake even through the proxy.

See Wikipedia:

The CONNECT method converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.

Even more details here:

A variation of HTTP tunneling when behind an HTTP Proxy Server is to use the "CONNECT" HTTP method.
In this mechanism, the client asks an HTTP Proxy server to forward the TCP connection to the desired destination. The server then proceeds to make the connection on behalf of the client. Once the connection has been established by the server, the Proxy server continues to proxy the TCP stream to and from the client. Note that only the initial connection request is HTTP - after that, the server simply proxies the established TCP connection.
This mechanism is how a client behind an HTTP proxy can access websites using SSL (i.e. HTTPS).

But note this caveat:

Not all HTTP Proxy Servers support this feature, and even those that do, may limit the behaviour (for example only allowing connections to the default HTTPS port 443, or blocking traffic which doesn't appear to be SSL).

share|improve this answer
2  
So, the proxy is not MITM'ing the HTTPS connection, by replacing the server's certificate with its own - it's simply passing the HTTPS connection straight through between the client and the server. Is that right? – mti2935 Feb 25 at 17:09
2  
Correct. It is still proxying the connection, at the TCP level - so it will be holding two TCP sockets, one in each direction - but will continue to pass the data back and forth, but will be opaque from the perspective of the proxy. The logical HTTP connection will be tunneled over these connections. – AviD Feb 25 at 17:12
2  
Yep for basic proxies, CONNECT is a tube punched through the proxy. I can see who you connected to, but not see any traffic or know who you connected to after that initial connect, unless your DNS resolution leaks. – Fiasco Labs Feb 26 at 0:54

Normally, when HTTPS is done through a proxy, this is done with the CONNECT mechanism: the client talks to the proxy and asks it to provide a bidirectional tunnel for bytes with the target system. In that case, the certificate that the client sees is really from the server, not from the proxy. In that situation, the proxy is kept on the outside of the SSL/TLS session -- it can see that some SSL/TLS is taking place, but it has no access to the encryption keys.

Some organizations implement a full Man-in-the-Middle by generating a fake certificate for the target server on the fly. They do so precisely so that the proxy can see the cleartext data and scan it to conformance to the organization policy (e.g. automatic antivirus scanning). This can work only if the client (your browser) accepts the fake certificate as genuine, which in turn requires that a special organization-controlled root CA is pushed on the client machine (and in a Windows / Active Directory world, a GPO can do that).

About all major vendors for firewall/proxy appliances offer that mechanism as an option.

Not all organizations deploy such a MitM system, for several reasons, including:

  • Automatic MitM can be expensive. The proxy appliance may have to be computationally powerful if there are many users; and the product license can be high.

  • MitM breaks certificate-based client authentication.

  • Doing a MitM makes sense only if you actually inspect the data, which again increases the computational costs.

  • The automatic pushing of a root CA does not work with BYOD.

  • As a rule, users really dislike such MitM.

share|improve this answer
3  
Another problem is that actual certificate errors must now be handled by the proxy server without user interaction. The proxy can only decide if they want to allow or deny it and the user is unable to check the certificate information themselves. With non-tech-savy users this might in fact be the better solution, but it might be counter-productive when your users know what they are doing. – Philipp Feb 25 at 17:15
2  
"As a rule, users really dislike such MitM." - only particularly technical users (such as software developers, sysadmins, etc) – immibis Feb 25 at 19:30
9  
@immibis: Any user who you actually took the time to explain it to would really dislike it. Lack of dislike is purely a result of lack of understanding. – R.. Feb 25 at 20:38
2  
More users are going to dislike as Chrome now refuses to work in that environment. – Joshua Feb 25 at 21:08
1  
@John And that makes perfect sense for applications. A friendly MITM should have absolutely no business intercepting the traffic from your Tinder application. A friendly MITM is usually there to help you with regular web traffic, such as content filtering. So I don't see how any grasp is slipping on MITM, unless you mean evil MITMS, which is a great thing. As far as general web, pinning is server based and trust on first use so, an active MITM can easily circumvent this feature anyway. – Technik Empire Feb 26 at 3:59

Your Answer

 
discard

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.