19

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?

gtmcclinton
  • 347
  • 1
  • 3
  • 6

2 Answers2

38

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.

Community
  • 1
Tom Leek
  • 172,594
  • 29
  • 349
  • 481
  • 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 '16 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 '16 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. – R.. GitHub STOP HELPING ICE Feb 25 '16 at 20:38
  • 5
    More users are going to dislike as Chrome now refuses to work in that environment. – Joshua Feb 25 '16 at 21:08
  • It seems that the grasp MitM once had is slipping as more mobile app developers are enforcing certificate pinning in their apps, making it nigh impossible to intercept. – John Feb 25 '16 at 22:16
  • 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. –  Feb 26 '16 at 03:59
  • 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. – CodesInChaos Feb 26 '16 at 08:56
  • Thanks, makes perfect sense, just hadn't heard of that method before – gtmcclinton Feb 26 '16 at 09:23
  • 2
    Not all organizations deploy such a MitM system, for several reasons, including: + this is illegal in some countries + this carries liability fo rthe company in some countries – WoJ Feb 26 '16 at 14:55
  • @John What does certificate pinning do that the normal method of securely connecting to a server does not? A man-in-the-middle appliance would not be able to intercept and then modify communications between a mobile application and a server because no certificate authority would ever give the user of the man-in-the-middle appliance a certificate that would let them pose as the server that the mobile application connects to. – Melab Aug 20 '18 at 01:20
  • 1
    @Melab if you can install an intermediate certificate on the client than you could sign for any domain. This is how normal SSL MitM works. But if you pin the certificate in the client then the client will reject the MitM generate SSL certificate for the target domain. – John Aug 21 '18 at 22:30
15

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

AviD
  • 73,317
  • 24
  • 140
  • 221
  • 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 '16 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 '16 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 '16 at 00:54