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?


2 Answers 2


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

  • 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, 2016 at 17:09
  • 4
    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, 2016 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. Feb 26, 2016 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.

  • 5
    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, 2016 at 17:15
  • 2
    "As a rule, users really dislike such MitM." - only particularly technical users (such as software developers, sysadmins, etc)
    – user253751
    Feb 25, 2016 at 19:30
  • 14
    @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. Feb 25, 2016 at 20:38
  • 5
    More users are going to dislike as Chrome now refuses to work in that environment.
    – Joshua
    Feb 25, 2016 at 21:08
  • 2
    @TechnikEmpire 1) I believe that browsers only apply certificate pinning when a preinstalled root certificate is used and disables it if a custom root certificate is used. 2) At least Chrome ships a list of preloaded pinned certificates. Feb 26, 2016 at 8:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .