0

This is partially a follow-up to the these questions:

Is visiting HTTPS websites on a public hotspot secure?

Can free Wi-Fi hotspot providers snoop on HTTPS communications?

I understand of course there this exists other ways to compromise your data when connected to a public hotspot (trick you into trusting unsafe certs, DNS redirects, downgrade attacks, etc).

I'm asking about the probability of your HTTPS data being compromised over an internet connection via the very specific attack vector of a compromised private key belonging to either a root or intermediate certificate authority that is already in your device's default trusted certificates (that is, the trusted certificates provided automatically by Mac, Windows or Android, for example).

Please correct me if my base assumptions are wrong, but my understanding is that if the private key of one of the trusted certificate authorities already on my device was compromised, than a malicious actor in possession of that key could perform a MITM attack on my HTTPS traffic when I'm connected to the network of that malicious actor.

Furthermore, my assumption is that upon detection the private key has been compromised, such a private key would need to be revoked. Any certs signed with that private key would become invalid until signed with a new, valid key, and my device would warn me when accessing a site using the revoked key.

Therefore my main inquiry is what mechanisms exist to detect that a root or intermediate key has been compromised? As a follow-up, how well protected are the private keys for my default trusted certs? Are there any metrics as to how long it would take for the revocation to reach my device (that is, how long the malicious actor with the compromised key could operate) or any evidence that such attacks via this vector are common on public hotspots?

Tronman
  • 101
  • 2
  • This is why we have certificate revokations lists (CRL's). See https://security.stackexchange.com/questions/5253/what-happens-when-an-intermediate-ca-is-revoked?rq=1 for more info. – mti2935 Jan 22 '23 at 23:51
  • How are certs determined to be compromised and added to this list? – Tronman Jan 23 '23 at 01:11

1 Answers1

1

what mechanisms exist to detect that a root or intermediate key has been compromised?

If the attacker uses the key to decrypt the traffic only, then there is no direct way to detect it. You can only suppose that it might have been compromised if you can observe events that with high probability are possible only if a third party obtained access to your communication data.

If the attacker uses the key to issue new certificates, this can be detected in some cases. There is a Certificate Transparency ecosystem, which can help the CA to check if there are any certificates issued in the name of this CA but not known to it. Also it can help domain owners to check if there are certificates for their domains that they have not requested.

how well protected are the private keys ... ?

One of protection measures is usage of HSM. See details here.

mentallurg
  • 10,256
  • 5
  • 28
  • 44
  • I'm not quite sure I understand. Are you saying a brower like Chrome could utilize the Certificate Transparency ecosystem to detect if, for example, a network owner was signing certs for domains they don't own using a compromised key? Or the Certificate Transparency ecosystem could help detect that a key has been compromised and issue a revocation, or at least recommend one, for a particular key? Or both? – Tronman Jan 23 '23 at 01:23
  • Neither. As I said, domain owner and CA both can detect an illegally issued certificate and revoke it. And if CA supposes the key was leaked, it can also revoke its own certificate. Browser checks only if the certificate was revoked. – mentallurg Jan 23 '23 at 07:34
  • Gotcha. My mistake. So then is it correct to say then that if the leaked key was only ever used on a private intranet, not externally accessible, it's not detectable in this way? – Tronman Jan 23 '23 at 10:07
  • No. It can be used everywhere. As long as the attacker only uses it to decrypt the traffic, this cannot be detected. – mentallurg Jan 23 '23 at 10:38
  • Wouldn't the attacker have to generate a fake cert in order to decrypt the traffic though? I'm only talking about the CA private key being leaked. Not the private key of the server I'm communicating too. – Tronman Jan 23 '23 at 12:10
  • If only the primary key of the signing key pair of CA is leaked, then yes, just intercepting the traffic is not sufficient. The attacker would need to issue a certificate and use MITM attack. Protection can be successful only in several conditions are met: If server sets the Expect-CT header, if browsers supports it, if browser contacted the server before MITM attack and noticed that this server requires Expect-CT, and if the fake certificate not registered yet in the Certificate Transparency log, then browser will refuse such certificate. In other cases MITM attack can be successful. – mentallurg Jan 23 '23 at 13:25
  • Gotcha. I think I understand much better now - thanks. – Tronman Jan 23 '23 at 14:31