7

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.

3
  • WRT, 'Each https page you visit now has an "instant" certificate that is issued by the security solution's CA' - Is the security solution's CA's certificate installed in the users' browsers?
    – mti2935
    Jan 5, 2022 at 17:14
  • "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." - CAA is not supposed to be checked by browsers, it's explicitly a mechanisms for CAs. I'm unsure where DANE falls wrt end-point checking.
    – marcelm
    Jan 6, 2022 at 12:38
  • 10
    The "security solution" you're describing is a MITM. Jan 6, 2022 at 17:14

2 Answers 2

16

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.

14
  • 11
    One potential gotcha I saw some years ago on a system using Blue Coat to inspect HTTPS traffic was that it implicitly validated a self signed certificate. From within a corporate environment running Blue Coat, I browsed to a web site using a self signed certificate. I received no browser warning as the browser saw only the validated BC certificate. It's pretty easy to see how this could be leveraged. Hopefully this has been corrected by now, I haven't re-checked. Jan 6, 2022 at 0:12
  • 8
    @user10216038: There were several papers in the last years regarding the security impact of trusted SSL interception, which also highlighted several more or less broken implementations - see security.stackexchange.com/questions/160846 and security.stackexchange.com/questions/158009 for some links. While the situation might be better now due to such research there are likely still broken implementations out there. Jan 6, 2022 at 7:04
  • No kidding. Last one that I saw was still a really broken implementation. I think the only way these can be made safe is to change to protocol so that they can still present the original certificate (say, by including it inside of the dynamic certificate).
    – Joshua
    Jan 6, 2022 at 20:20
  • @Joshua - You can't, since if the real endpoint is contacted via the real cert the MITM has no way to read the information, which defeats the whole point. Jan 6, 2022 at 23:05
  • 1
    @user10216038 Always test your new HTTPS sniffing tool by purposely loading websites with bad certificates, for example: badssl.com
    – Ferrybig
    Jan 7, 2022 at 12:02
13

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

2
  • A key thing that IMO would improve this answer is that trust in a certificate is established via some kind of side channel. We trust CA certificates because they come pre-installed on the CD stamped with the holographic Windows logo. Trust in a self-signed certificate is established the same way. Ideally this means distributing it via a physical side channel. If you have to transmit it via an insecure channel, you could verify its hash via a side channel, like verify the hash over the phone before a MITM attacker would have time to create their own key with a hash collision. Jan 7, 2022 at 19:07
  • Well, I just used the work laptop as an example, as this is where I first observed this behaviour. For a successful MITM attack, all you need is a valid certificate for the target site. This is a thing that has happened in the past and may happen again. The Signal desktop client seems to do it right and refuses to connect. I'm still puzzled how browsers will accept "wrong" certificates "just like that". Or would a browser actually check the CAA record if the root wasn't installed in the browser?
    – Bebef
    Jan 13, 2022 at 7:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .