How the NSA are reading your HTTPS traffic

I plan to write two posts about the NSA/GCHQ ability to intercept and record encrypted traffic on the Internet. This one is on the technical feasibility and possible methodology. If you don’t understand SSL/TLS you are unlikely to understand this post; the point is that it is very plausible that they are doing what it is alleged they are doing.

Here is how I would be reading your HTTPS traffic if I had their budget, resources, and any inclination to do it.

The simplest method is to create a man-in-the-middle attack: install a ‘transparent’ proxy between the client and the server. For this to work, the proxy needs to be able to create server certificates in the name of the site to which the client believes they are connecting. Furthermore the client believe that the generated (fake) server certificate is real. You can try this for yourself at home by creating a CA key and certificate, adding it to the trusted CAs on one of your client computers, and configuring a Squid proxy server (version 3.3 or later) to use the key for dynamic SSL certificate creation. If you then configure things so the client connects to the Internet through that Squid proxy, all of its HTTPS traffic will be decrypted then re-encrypted in the proxy server. Your client will see that all the https sites it accesses are secure; if you inspect the security certificate on the client you will find that it was signed by the CA you made earlier.

If you want to feel like the NSA, you can trivially set squid to log all the request and response headers which go through it; if you want to log the request and response body data you will need to adapt the squid code (slightly) to make it possible.

Let us presume, for a moment, that the NSA haven’t installed their own CA certificate on all our computers without our knowledge. How then, can they make this work? It’s simple if you presume that they have access to the keys which correspond to all the root CA certificates which are implicitly trusted by your browser. They could have got the keys in a number of ways: thefts, secret court orders, brute-force attacks on the CA certificates, or (considerably less-likely in my opinion) by exploiting weaknesses only they are aware of in the RSA or DSA algorithms. This also allows their proxy to sign the fake server certificate with the same CA key used by the real server, considerably reducing the chance of anyone spotting the difference.

I think this is how they are doing it. It seems more plausible to me than the other possibilities:

  • They have broken all the symmetric-key ciphers in common use.
  • They have broken all the asymmetric-key ciphers in common use.

3 Responses to “How the NSA are reading your HTTPS traffic”

  1. Fritz

    Doing MITM for the entire internet seems implausible to me.

    I’d be more inclined to believe that they’ve stolen or recovered the private keys of the major website certificates that they’re interested in. Or used National Security Letters. Then, they could even use Wireshark to decrypt the traffic at their leisure. I do this all the time with my own applications for debugging purposes.

    Doesn’t work for ephemeral modes of TLS, however I doubt any major service uses these modes.

  2. Lester Heval

    Yes. I agree. Getting their hands on the private keying material for the root CAs that are trusted by web browsers is going to be considerably easier than breaking the ciphers being used to encrypt the data. And they only need to gain access to one trusted root CA private key to make it happen. There are hundreds of trusted root CAs. Worst case, they have to get an employee (spy) into the target organization, let them work for a couple years to become a trusted employee, and then one day, leak the private key out the door on a USB stick, and then quit six months later for a different job. Then all they need is one of those nifty little Man-In-The-Middle (MITM) routers that the FBI uses, load the CA, and, unless you’ve got plugins installed into your browser to detect certificate changes, the user is none the wiser. To somewhat counter this, certificate changes need to be detectable by browsers and applications out-of-the-box, not with plugins.