11

As Bruce Schneider reported here...

https://www.schneier.com/blog/archives/2013/09/new_nsa_leak_sh.html

...the NSA reportedly performed a MITM attack on a company in brazil and decrypted their SSL traffic by compromising their router. The commenters also mention a similar attack against the DigiNotar CA a while ago.

My question is, in either case, would the SHA1 thumbprint of the SSL certificate have been changed by the MITM attack? Theoretically, if someone was paying attention and saw that the thumbprint was different, they could have known they were being spied upon, right?

2 Answers 2

12

and decrypted their SSL traffic by compromising a backbone router

No, that's wrong (but it doesn't impact the rest of the question). According to that claim, the NSA compromised a router that belonged to the target (not that it really matters). More importantly, compromising the router did not help the NSA decrypt the SSL traffic: all it did was allow the NSA to perform a man-in-the-middle attack on the encrypted-and-signed stream. If all the aspects of SSL had held, that attack would have been detected and the NSA would not have been able to decrypt legitimate traffic.


The decisive part of the attack was that the NSA could craft a fake certificate for Google. An SSL certificate roughly contains the following parts:

  • A description of who the certificate belongs to (Google)
  • The public key of that entity
  • A description of who vouches for the certificate (the CA)
  • Some mathematical magic that ensures that only the holder of the private key of the CA could create that certificate

It appears that the NSA knew the private key of the CA, hence they could create a certificate containing a different public key, which corresponded to a private key created by the NSA instead of the private key held by Google.

Since the fake certificate is different from the genuine one, it has a different fingerprint. (Note that this may not be the case for MD5 fingerprints: MD5's collision resistance is sufficiently broken to allow the creation of two certificates with the same fingerprint — but not to craft a certificate with the same fingerprint as an existing certificate. But no such vulnerability is known for SHA-1.) Therefore if you detect that the certificate's SHA-1 fingerprint is wrong, you know you are being actively man-in-the-middled.

This is of limited practical importance, because you have to be able to retrieve that SHA-1 value reliably somehow. Where are you going to find a trustworthy connection to retrieve these fingerprints?

Spreading the verification across several parties is one way to resist the compromise of a small number of CAs while allowing browsing hitherto-unknown sites.

6
  • 3
    Browsers accept a profound variety of Root CAs and most people don't use a tool to detect certificate changes (these tools prompt so often as to be intensely inconvenient anyway). So spy agencies only need to A) Breach a root CA or B) Set up a fake root CA company. I doubt non-profit browser development foundations have the resources or time to back-trace every shell company. Sep 13, 2013 at 23:36
  • 1
    The kerfuffle a few years back about the CNNIC Root CA was cultural relativism, as many other pre-trusted Root CAs are explicit nation-states. But it did for the brief moment it was in the news, highlight the inherent flaw of top-down trust in the SSL protocol (as implemented in consumer platforms). Sep 13, 2013 at 23:47
  • Fixed the backbone router assumption.
    – John
    Sep 14, 2013 at 23:04
  • 6
    @Gilles: it may be worth noting that though MD5 is sufficiently broken to allow the crafting of two distinct certificates which hash to the same value, it is not broken enough to allow the crafting of an extra certificate which hashes to the same value as a given, non-malicious certificate. Sep 15, 2013 at 0:08
  • 3
    @Gilles "Where are you going to find a trustworthy connection to retrieve these fingerprints?" The CertificatePatrol Firefox plugin was created for this problem specifically!
    – executifs
    Apr 3, 2014 at 8:07
0

To detect a MITM attack, you need some way to communicate with the other end that is not easily tampered with by a third party. If there's a MITM attack, the key you're using is different than what the other end is using, and the crypto bits are different.

A classic way to do this appeared in some early public-key phone encryption units. After call setup, a 2-digit number based on the public key in use would be displayed at both ends. Both parties would then verify by voice that they saw the same number. An intruder would need to be able to seamlessly replace part of the users' conversation to get away with an MITM attack.

This suggests a path to more general solutions. Existing MITM attackers usually just pass through the plaintext (although they may introduce attacks). With appropriate software at both ends, the MITM attacker has to generate a consistent lie to both ends. It may be possible to make the attacker work arbitrarily hard to generate that lie.

You must log in to answer this question.

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