How to prevent HTTPS man-in-the-middle with self-signed certificates?

Question

I came across this issue when we implemented a new security solution. Said solution has its own root CA certificate and will create certificates for HTTPS web pages "on the fly". Each HTTPS page you visit now has an "instant" certificate that is issued by the security solution's CA and not its original certificate.

What you now basically do is communicate with the security solution, which acts as a proxy. It "breaks open" TLS traffic, inspects it, and in turn (re-)establishes an encrypted connection to the target web server.

Now, what if it wasn't a security solution, but a malicious actor who did this? This would be a very easy and convenient way to perform man-in-the-middle attacks. Is the installation of a CA certificate in the browser really the only thing between secure TLS connections and a MITM nightmare?

We have several (failed?) mechanisms which might prevent this, such as DANE or DNS CAA, but as it seems, none of those actually is being used by modern browsers.

Is there a way (in 2022) to prevent someone from just creating a TLS certificate and posing as another party in a way DANE or DNS CAA were supposed to do? I'm talking about actually preventing a client connecting to a server serving the wrong certificate, not just monitoring issuance like Certificate Transparency does.

Answer 1

What you describe is the normal way corporate firewalls or antivirus inspect HTTPS traffic. Browsers will by default block access to these sites and users are not supposed to click though the warnings. Instead the CA of the proxy needs to be imported as trusted into the browser/system, which is usually done automatically in corporate environments or when installing a local antivirus product.

Is there a way (in 2022) to prevent someone from just creating a TLS certificate and posing as another party ...

There is no way to prevent others from creating arbitrary certificates signed by a CA not trusted by most users. Only such certificates will not be trusted by sane clients, so there is no actual risk here to address.

SSL interception by an explicitly trusted party instead serves an accepted purpose. While it breaks end-to-end security and thus decreases security, it provides an actual security benefit by doing content inspection to protect against malware etc. And it does not allow an arbitrary attacker to be man in the middle since such an attacker has no access to the trusted CA certificate.

Answer 2

Is the installation of a CA certificate in the browser really the only thing between secure TLS connections and a MITM nightmare?

Installing a CA certificate in the browser (or the OS-level trust store that the browser uses) is ultimate trust. It means "if the bearer of this cert attests that I'm talking to foo.com, then I'm talking to foo.com". Yes, that puts the holder of that certificate in the position to MITM everything — but only for devices that place trust in that cert. In order to MITM someone this way you either have to control their device sufficiently to install your cert in its trust store, or else subvert one of the big-name CAs that everyone trusts by default.

[Corollary: you definitely don't have any privacy on a work-issued laptop. Don't use it to read your personal mail, check your bank balance, or anything.]