Is HTTPS private?

Recently, in one of the blogs I read, I saw an interesting statement (in my free translation):

Do you think when you work with online banking from the office, you have an end-to-end secure connection? Think again.

Enough to interest and dig a little. “And what do you think? (c) ”At least two intermediaries (Man In The Middle) can be embedded into the“ completely secure ”HTTPS connection. True, both must be Trusted (TMITM), so there is no need to panic very much. For now.

Option 1: corporate / carrier firewall or proxy

On corporate networks, users usually access the Internet through a proxy, which can be set explicitly or implicitly (transparent or just an advanced firewall). This is necessary to maintain at least minimal corporate control over traffic (filtering unwanted sites / scripts / ads, anti-virus checks, caching, etc.) and, in principle, is logical.
It’s absolutely clear how this works for unencrypted HTTP, but with HTTPS, not everything is clear. After all, HTTPS is just designed to protect against "crashing" into the session and intercepting traffic: data is encrypted, and the authenticity of the server is verified by certificates. So, at least two questions arise:

1. Why should I trust a proxy certificate?
2. Even if I trust the proxy certificate, it is issued in the name of the proxy, and not in the name of my bank - how can it work?

It turns out that it can.

The first question does not arise at all if the company has its own certificate infrastructure and has its own CA. In this case, the certificate of this CA will be installed as trusted on each working machine, and everything that will be signed by the same certificate (our proxy) will also be trusted. It is because of this that such a “trusted” implementation becomes possible in this scenario.

But what to do with the wrong name in the certificate? There is (and quite a long time ago) a class of programs like MITMproxy or HoneyProxy that successfully solve this problem. Their main function is to read in Apple GameCentergenerate certificates on the fly! The proxy is installed as an intermediate CA (signed by Enterprise Root CA) and dynamically generates certificates (for itself) for any name. Thus, the client thinks that he is talking with the bank, although, in fact, his HTTPS session ends with a proxy.
Details here .



So, the initial statement turned out to be true, and working HTTPS connections can only be trusted as much as you can trust your IT department. Or use a browser like Firefox, which has its own OS-independent certificate store and certificate pinning support(not so long ago became popular in browsers). Well, or, of course, not to use work machines in the work network for non-business purposes, but who will follow this stupid rule? VPN can also help if it is not based on SSL.

UPD: In the comments, they came up with the idea that the same thing could happen if you use a smartphone “from the operator” with operator firmware - the probability of finding the default trusted certificate for the entire operator’s infrastructure is close to 100%.

Option 2: CloudFlare Keyless Cloud Proxy

Well, in the first case, there is a proxy that is in my office and which initiates connections on my behalf. Anyway. In any case, the target server to which I connect must be authentic - otherwise the proxy will panic and will not build an HTTPS session before it (unless the admins got it right with the setting). In light of the recent announcement of CloudFlare's Keyless SSL , it seems that this is no longer a fact either.



Technical details can be found here . It is important for us that in this scenario the target server (the same online banking) is already, it turns out, the bank does not already belong! The good news is that it belongs to someone the bank trusts.

CloudFlare mates have developed a way to introduce themselves as a customer’s HTTPS server without having to forge certificates or even sign with customer keys. In fact, just the authentication check is carried out with the bank server, but as soon as it is passed, the session is established with the trusted CloudFlare server. The noble goal is to offload client HTTPS traffic and protect against DDoS attacks. How long will it take to invent a method of impersonating a target server without having to obtain its certificates and keys (or how quickly the “authorities” of different countries will require backdoor access) - who knows? Hopefully long enough.

Total

In a seemingly “safe from and to” HTTPS connection, at least two intermediaries can successfully settle down. Both should be trusted, but your admin trusts them, your boss, your bank, your store - just not you. If you think that the Internet still has 100% privacy, think again .

Do you know any other attack methods on HTTPS?

PS The original is here .