2

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.

  • Partial answer: SHA Fingerprint probably not, as well as serial number. – Vilican Jul 2 '15 at 21:07
  • If a MitM uses a fraudelent certificate: The certificate by itself will change, the hash (=fingerprint) will change, the padlock will stay, the CA will change, how to defend? There're browser extensions checking certs against "known-goods" / "what-everyone-sees". – SEJPM Jul 2 '15 at 21:12
8

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.

  • s/IE with ESET/IE with EMET/ (Blog guy says it works. I don't know. I've never tried this.) – StackzOfZtuff Jul 3 '15 at 14:20
  • Thanks, but specifically I am not interested in whether the browser would accept it, rather whether a user looking at the certificate could know that it was not the original. I mean, is this type of MITM attack detectable on the client side by someone who is directly looking for it? Does it matter which root CA is compromised (i.e. the original root CA or a different one)? – daveonhols Jul 3 '15 at 21:46
  • @daveonhols: it is detectable because the certificate changes and you might look at the fingerprint. But nobody would check the fingerprint on each request and probably does not even remember the previous fingerprint. And here the described extensions help. It does not matter who issued the fake certificate, because the new certificate has a different public key than the original one. If not than not only the CA but the owner of the certificate itself got compromised in which case the attacker has access to the private key and does not need to compromise the CA. – Steffen Ullrich Jul 4 '15 at 2:46
3

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.

  • OCSP/CRL do not help much. The OCSP and CRL URLs are contained in the certificate itself and thus might point to a URL controlled by the attacker. Of course this depends on the process how the fake certificates were generated but after the DigiNotar attack they shipped updates to all major browsers because the usual revocation mechanism did not work. – Steffen Ullrich Jul 2 '15 at 21:45
  • Yes, they don't help much but they do something (albeit little). I agree with you though, and this underscores my point about the CA chain-of-trust model being long broken, catering to rackets charging exorbitant money for doing basic checks and signing certificates. Adoption of protocols like DANE and DNSSec really needs to take off to end this. – Herringbone Cat Jul 2 '15 at 22:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.