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.
If an attacker could coerce a legitimate root CA to produce fradulant TLS/SSL certificates, they could use those certificates to impersonate that user. This is why the Superfish issue was such a big deal. A root CA wasn't compromised, but instead they added their own root CA to a bunch of machines before selling them to clients. This allowed them to MitM all of the traffic, without the users being any wiser.
There are also special protections that can be put into place to prevent against this.
One such protection is the HTTP Public-Key-Pinning (HPKP). You can insert a header that specifies your websites public key and the public key of one of the root CAs. The browser will store this list, and will terminate any connections that don't match this. So, if you tried to MitM my connection to Facebook (if they used HPKP), my browser would throw an error and not allow the request to go through.
By specifiying a root CA in the HPKP, it says that only that rootCA can sign your certificate. If you specified DigiCert in your HPKP, your browser would not accept a certificate that was signed by Comodo.
In thick clients or mobile applications, you can do something similar, called Certificate Pinning. Basically when developing an application, you can specify what certificate is required to be returned by the server. If that certificate isn't specified, the request will fail. You could also specify that the certificate must be signed by a specific root CA.
There is also something known as the Online Certificate Status Protocol (OSCP). The browser will make an additional request to the root CA to verify the status of the certificate. This will check if it is revoked or not. Here it would depend on how badly you had compromised the rootCA. If your fake certificate failed the OSCP verification, the browser would hopefully notify the user.
I'm not positive exactly what you mean about having the correct SHA keys. SHA1 and SHA2 are hashing algorithms, which do not have keys. Certificates often have two things which use the SHA algorithms. First, they will contain the certificate signature. This typically is a SHA2 of the certificate contents, which is then signed by the root CA. The certificate also contains a thumbprint, which is a SHA of the entire certificate. Changing any of the contents of the certificate would change it's thumbprint. However, you would need another band of communication to know what the expected thumbprint is.