How is it possible to do TLS through proxy without anyone noticing?

Question

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?

Answer 1

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).

Answer 2

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.