Could a compromised root CA impersonate any SSL certificate?

Question

My question is about MITM attacks against https and how those would appear to the end user.

Suppose a trusted root CA were compromised / coerced into producing fraudulent SSL certificates. What would such certificates be able to achieve, specifically about MITM type attacks?

For example take Facebook, if I go there I get (1) a padlock, (2) a certificate signed by DigiCert, and (3) I can check the SHA Fingerprint matches some value 81:AB:etc.

My assumption is that if DigiCert were the compromised CA, then a fake certificate matching 1, 2 & 3 could be produced, is that correct? Is there anything else in the SSL security model that would make a fake certificate distinguishable from the real SSL cert that was actually issued to Facebook? Or anything else that would allow detection of MITM type attack based on this cert?

My second assumption is that if a CA other than DigiCert were the compromised CA, then a fake certificate could be produced, but it wouldn't say "DigiCert" on it, and it wouldn't match in terms of SHA key? Is that correct, or would it be possible (purely from a technical point of view) for a root CA to create a certificate impersonating another root CA? If so, would there be any other way to detect that a connection was encrypted with this fake cert? Could another CA create a cert apparently having the same SHA key?

This question is inspired by Britain's upcoming "snoopers charter" which is slated to give the authorities many powers to spy on digital communications. The point being how useful such powers might be in the face of encryption, as there has been some talk of using "black boxes" performing deep packet inspection to collect information that providers (eg Facebook) might not choose to share with Her Majesty's Government. My guess was that such techniques are not possible (certainly not with DPI I would hope!) but the possibilities of fake certs and MITM attacks is not really clear to me. I am guessing it wouldn't be attempted if only for political reasons assuming fake certs could be detected by tech-savvy clients.

Answer 1

Such compromises already happened and DigiNotar is just on example. In effect the attacker could impersonate almost all certificates this way, because for most certificates it does not matter who signed it but only that it was signed by a CA trusted by the browser.

There are few exceptions which are thus safer:

• Chrome and Firefox (and IE with EMET?) have the fingerprint of the public key for some very important sites hard coded (pinned) in the browser/OS. In this case the fake certificate will be detected, as was done in the DigiNotar case.
• With HPKP sites can offer their keys for pinning into the browser on first use, even if the browser was not shipped with these keys pre-pinned.
• Extended Validation certificates (EV) can only be issued by selected CA, which are hard coded into the browser.

Of course one could in theory detect such wrongly issued certificates by comparing the fingerprint. There are extensions like Certificate Patrol which notify the user if the certificate of a previously visited site has been changed, but it is still up to each user to decide if the change was correct or if this would be an attack. Extensions like Perspectives try to simplify this process by comparing the certificate against the certificates seen by other users. But none of these facilities are currently shipped with the browsers.

Note that this re-creation of certificates is often done legally in SSL intercepting firewalls, which need to get access to the decrypted content in order to detect attacks. But in this case the new root CA is explicitly added to the browser as trusted. For these CA's, which are not shipped with the OS/browser, HPKP and pre-pinning are usually ignored by the browser.

Answer 2

The compromise of a Root CA does not mean that all certificates signed by that trusted root are indeed compromised. Rather, it means that fraudulent certificates can be made for man-in-the-middle attacks and signed so they appear trusted in a browser.

When you submit your Certificate Signing Request (CSR) to a Certification Authority (CA), they are actually signing your public key. This indicates that they have validated your ownership of the domain, along with any other protocols that CA requires, to prove your identity. Since you do not send your private key, this does not allow them carte blanche to be able to decrypt your traffic, as your private key remains private.

It is very difficult to compromise a root CA. In order to be trusted by browsers, there are strict requirements for security. This includes the "key ceremony" which effectively renders signing anything with the root key into a very cumbersome and lawyered operation. This is why most CA's sign with an intermediate, rather than directly from the root.

If someone were to let's say compromise DigiCert's intermediate signing key, then they could issue all the certificates they want. However, they would still not control DNS for those domains. They could however, for example, hack DNS on a corporate or home router and conduct a man-in-the-middle attack for let's say, Facebook, without the browser displaying a warning. The attack would use their DNS-hacked web site to be a proxy to Facebook where they could intercept the traffic.

This is done on a large scale by corporate firewalls with SSL interception (they replace SSL certs with their own, which is trusted by all the workstations, and then re-encrypt it with the right certificate and send outward). It's also done by countries like China, who require their CA be trusted by all computers and conduct SSL middleman attacks like this as a matter of course.

A newly-generated certificate would not match the previous key's SHA fingerprint. Any minor difference in a file or string hashed with SHA would differ greatly from another version due to what is referred to as the "avalanche effect" in hashing. However, this won't matter for browser trust -- people replace certificates all the time and browsers don't check for the hash remaining constant. Instead, they use CRL (Certificate Revocation List) or the more modern OCSP (Online Certificate Status Protocol) in order to query the CA and see if a certificate has been revoked or compromised. This is the second layer of defense against a compromised certificate chain.

Outside of OCSP/CRL however, only user vigilance can detect a potentially compromised certificate chain. This is why I believe it has been long in coming that a replacement for the CA chain of trust model be widely implemented, for example DNSSEC.