Hacker News Reader

    > They just need to have bought/stolen/subpoenaed/cracked the private key of any CA

The CA's private key isn't involved in the encryption. It is used the sign the SSL certificate. Google's private key or a flaw in the crypto algorithm is needed to decrypt the traffic and that is most probably what the NSA is doing.

They are roughly 30 years ahead in crypto analysis. They have shown this when they gave us hints on hardening the current crypto algorithms to make them secure enough for todays use (like online-banking, secure ordering over the Internet etc). They however have no problems with them.

> They are roughly 30 years ahead in crypto analysis.

For various definitions of "roughly"...

They were 30 years ahead when they tipped their hand around DES.

Today? Who knows.

If you have the private key of a trusted CA (e.g. a CA in the browser), then you can sign a certificate for any site.

E.g. if your browser trusts RSA as a CA, and I had RSA's private key. Then I could create a new certificate for any site I want on the fly and sign it with a CA's key that your browser trusts.

There are several products that do this (E.g. Bluecoat's Proxy-SG) to filter/cache SSL traffic for enterprise customers. In these cases they just create their own in-house CA and add it to the standard install of all their corporate browsers. If you had the private key of any trusted certificate authority (and there's a scarily large number of them, including ones owned by governments) then you could create certs on the fly for any site and decrypt all traffic.

Trust me - I've built products that do this, and written entire an entire SSL stack from scratch.

Well you would be right in terms of this working but if the NSA were doing this it would have been noticed. Also, that trick won't work when certificate pinning gets involved so going to Gmail in Chrome would pop up a warning message if they tried. Supposedly PRISM has access to Gmail so at the very least the NSA is doing something else in addition to selective SSL MITM attacks.

You can use something like Channel ID[1] to bind the D-H connection into the bearer token used for authentication (i.e., an OATH token). This won't protect against a MITM attack per se, but laptops and mobile devices tend to connect to a number of different networks, and if the MITM proxy is located close to the user, it's hard to make sure that all possible connection avenues from the laptop in question can be intercepted (including if the user hops on and off a VPN). If the user manages to connect to the server without going through the MITM, the channel ID will be different and so this can be noticed.

[1] http://tools.ietf.org/id/draft-balfanz-tls-channelid-00.txt

If the MITM proxy servers are located close to the server, this problem goes away, but now the problem is since the ID information is passed after the D-H encryptionis established, and laptops move around, the MITM proxy would have to attack everyone's SSL connection. This increases the likelihood that someone will notice, and more importantly would require a huge amount of computing equipment. This is not something that you could hide in a phone closet --- and given how carefully most data centers measure power utilization and air conditioning load, a massive MITM proxy farm would be easily noticed.

> This would then enable a man-in-the-middle SSL attack.

We know they are not doing this en-masse though. It would be noticed by now if they were. They undoubtedly do it, but almost certainly only targeting individuals, or all users of obscure sites.

A man-in-the-middle attack done this way would be easy to detect. You just need to compare the site's key with the one you received, and they'd be different.

Or, in simpler terms, that kind of attack would require the cooperation of several employees of the attacked companies. While just putting a mole there and copying the private key would require cooperation of only the mole in one of the positions that would need to cooperate at the other attack. (And breaking the key would happen only if the NSA wanted to give some easy money to computer manufacturers.)

Rougue certificate authorities are the biggest weakness of SSL from the point of view of a user that wants to be sure that it's really his bank that is asking for a password. But the endpoints security are still the biggest weakness against a powerfull oponent like the NSA.

> The NSA doesn't need to break Google/Facebook/Twitter's private key.

Bill Binney has already said [1] this is exactly the case:

"No online cipher is safe...

Simply because if they don't have the key, they will come across and get it from you (that's assuming they didn't already implant it in your system).

The safest way is to do encryption offline, then go online and send it, and do decryption offline... If you don't have an air gap, you're not safe.

...I don't think they have to break [the encryption keys] at all. They already have them. That's my point. No online system is safe."

[1] http://techtv.mit.edu/videos/21783-the-government-is-profili... ~33 minutes

This should help. http://tools.ietf.org/html/rfc6962

What luck for China that everyone distributes and trusts their CNNIC CA key and Hong Kong Post's CA key.