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, do you have an end-to-end secure connection? Think again.

Enough to interest and dig a little. “And do you think? (c) "You can embed at least two intermediaries into the secure secure HTTPS connection (Man In The Middle). True, both must be Trusted (TMITM), so do not panic much. For now.

Option 1: corporate / carrier firewall or proxy

In corporate networks, users usually access the Internet through a proxy, which can be specified 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 / advertising, antivirus checks, caching, etc.) and, in principle, logical.
It is absolutely clear how this works for unencrypted HTTP, but with HTTPS - not everything is clear. After all, HTTPS is precisely designed to protect against “embedding” in a session and intercepting traffic: data is encrypted, and server authenticity is checked with certificates. So, at least two questions arise:

1. Why should I trust the proxy certificate?
2. Even if I trust the proxy certificate, it is released 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 deployed 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" (Trusted) implementation becomes possible in this scenario.
')
But what about the wrong name in the certificate? There is (and quite a while ) a class of programs like MITMproxy or HoneyProxy, which successfully solve this issue. Their main function is to read Apple GameCenter to generate certificates on the fly! The proxy is installed as an intermediate CA (signed by the Enterprise Root CA) and dynamically generates certificates (for itself) in any name. Thus, the client thinks that he is communicating with the bank, although, in fact, his HTTPS session ends in a proxy.
Details here .



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

UPD: In the comments suggested that the same thing can happen if you use a smartphone "from the operator" with the operator's firmware - the probability of finding the default trusted certificate for the entire infrastructure of the operator is close to 100%.

Option 2: CloudFlare Cloud Keyless Proxy

Well, in the first case there is a proxy that is in my office and that 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 not build a HTTPS session before it (unless admins are messing with the settings). In light of the recent announcement of Keyless SSL from CloudFlare , it seems that this is also not a fact.



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

Comrades from CloudFlare have developed a way to present the client's HTTPS server without having to forge certificates or even sign with customer keys. In fact, the authenticity check is performed with the bank’s server, but as soon as it is completed, the session is established with the trusted CloudFlare server. The goal is noble - offloading HTTPS client traffic and protecting against DDoS attacks. How much time will be needed to invent the method of impersonating the target server without the need to receive its certificates and keys (or how quickly the “authorities” of different countries will request backdoor access) - who knows. Hope long enough.

Total

In a seemingly secure “to and from” HTTPS connection, at least two intermediaries can successfully settle. Both must be trusted, but your admin, your boss, your bank, your store - only you do not trust them. If you think that there is still 100% privacy on the Internet - think again .

Do you know any other methods of HTTPS attacks?

PS Original here .