Does HTTPS really provide 100% privacy?

It all started with this blog mentioning HTTPS MITM possibilities. Quote:

Do you really believe you have end to end secure connection with your bank when you access your account from the office? Think again.

This got me into some research, especially after a few days later an announcement from CloudFlare came out. Here are the results: there are at least two scenarios for TMITM (Trusted Man In The Middle) HTTPS interception.

The corporate firewall case.

In corporate networks users typically access Internet via an explicit or transparent proxy. This allows enterprise IT to maintain some degree of control over the traffic (blacklisting untrusted websites, cut out dangerous web scripts/ads or simply cache popular content to save uplink bandwidth). It’s pretty obvious when it works over plain unencrypted HTTP, but HTTPS assumes end-to-end encryption and endpoint validation! Even if proxy were there, there are two fundamental problems:

1. Why would I trust the proxy’s certificate?
2. The proxy’s certificate will be issues in proxy’s name, not the target website’s name.

Seems logical, in the end – this is the intended use for HTTPS: prove authenticity and prevent eavesdropping. Well, let’s have a closer look:

1. Problem #1does not really exist in corporate environments that have their own CA infrastructure. Most likely, each corporate device will already be configured to trust the enterprise root CA, and thus, everything that is signed with root CA certificate. This is why this kind of trusted MITM intrusion is possible.
2. But what do we do with the certificate names? Enter MITMproxy (and the like, this is not the only tool out there that does it). This open-source piece of software does a simple trick: it allows you to cheat on GameCenter dynamically generate certificates on the fly! This way, when you talk to, say, your bank, instead you really talk to the proxy, that presents the certificate that you trust in the name of your bank! More details here.

Thus, the initial quote holds true.You can trust your HTTPS connections at work only as much as you can trust your IT department. Workaround would be using a browser like Firefox that allows configuring its own list of trusted certificates (independent from the OS) and supports Certificate Pinning (which also was announced not that long ago). Or, of course, don’t use corporate device on corporate network for non-corporate business but who would follow these stupid restrictions, right? 🙂 VPNing might also help, as long as it’s not SSL-based 🙂

The CloudFlare cloud HTTPS proxy case.

OK, so in the first case we had our Enterprise firewall/proxy connecting to the server we want on our behalf. But at least we could still be sure that the website we’re connecting to is genuine (unless the proxy was badly misconfigured). Looks like this could be no longer the case with the recent announcement of Keyless SSL from CloudFlare.

You can read the Nitty Gritty Technical Details here, but what’s important for us, is that in this case even the destination, online banking for example, server is not actually owned by the bank! Good news is that it’s owned by someone the bank trusts and allows them to act on their behalf.

This implementation is more clever that the previous case, since there are no spoofed certificates involved. In fact, all the authenticity checks are carried by the target server (i.e. your online banking server), but the session is established to the proxy. The goal is noble – to allow cloud data offload and protect from DDoS attacks. How long will it take for someone to device a server-end identity hijacking without even having to steal private keys – I don’t know. Hope it will take long enough 🙂

Summary and conclusion

There can be at least two MITM proxies in your seemingly ‘end-to-end secure and authenticated’ connection. For now, both of them must be trusted, albeit by someone that is not you, but your boss, your admin or your target service provider (online shop, bank, etc).

There is no such thing as privacy on the Internet. Get used to it, if not already.