Hacker News Reader

Comment by JunkDNA | Hacker News Reader

Beam splitters (prisms?) inside the backbone providers. All traffic goes to its destination unharmed, but the NSA gets all the packets. SSL is harder, but all you need is the private keys. Those are hard to get but not impossible for someone with the resources of the government. This is the only scalable way to do what they are supposed to be doing and not involve lots of outsiders. Note that the people who have really clammed up the past few days are the telecoms in all this.

View on HN

This is exactly the conclusion I came to. My guess is they have the SSL/TLS keys.

That being said, tptacek thinks we are wrong, and he is a subject matter expert, so I am not sure.

The linked quora answer (from the co-author of Firesheep) says that even in that case one can't launch a passive man in the middle attack if perfect forward secrecy is used. Google.com uses Diffie–Hellman key exchange which provides perfect forward secrecy.

So... If I understand everything correctly, it should be impossible to decrypt passively captured HTTPS traffic to/from google.com.

http://www.quora.com/SSL-Secure-Sockets-Layer/Is-it-ever-pos...

Could someone more knowledgeable confirm this?

actually everyone seems to have switched to the "fast" SSL ciphers instead - only dropbox defaults to DHE:

> openssl s_client -connect google.com:443 RC4-SHA > openssl s_client -connect dropbox.com:443 DHE-RSA-AES256-SHA

Again, this is usually done for speed, but all of the companies on the list are using "fast" SSL/TLS ciphers rather than more secure ones.

Thanks for this. "Dropbox coming soon" indeed.

I not really an expert in this at all, but we were not discussing ciphers, but key exchange methods.

I open google.com in Chrome, click on lockpad icon, go to the second tab, and it says: Key exchange method: ECDHE_ECDSA

Some googling turns up that: "ECDHE-ECDSA provide perfect forward secrecy" http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forw...

yes it appears Google has PFS for Chrome/Firefox: http://www.imperialviolet.org/2011/11/22/forwardsecret.html

We are not disagreeing with anything he says. We are saying the NSA has the private key.

Ian Gallager: > so if you have the private key, you can decrypt that key, and then use it to decrypt the bulk-encrypted data.

Like he says, if you have the key, wireshark can decrypt the data trivially.

If you have the CA master keys, then the only thing you can do is perform a MITM attack, but not silently decrypt the raw data. A MITM attack would eventually get detected.

Ephemeral Diffie-Hellman creates a new key per connection in a public-safe manner. You cannot eavesdrop on such a connection, even if you have the signing key. The question then becomes, are the SSL sessions actually using that mode.

> Ephemeral Diffie-Hellman creates a new key per connection in a public-safe manner.

How does that make a difference when you have the Diffie-Hellman key? We are saying they have the Diffie-Hellman keys, not the signing keys, nor the block cipher key that is exchanged. They have the only key that matters.

How are they getting the DH keys without cooperation from at least one of the SSL endpoints involved? They're newly generated at every SSL handshake, you can't just get a mole to hand you the keys once and be done with it. If you had the certificate private key, you could do a MITM, but this requires a LOT more resources and would be much more easily detectable.

I was clearly wrong.

But I am still lost on how it would be detectable? From Google's end, some client just disconnected. From the client's end, the internet just got a tiny bit more latency.

If you had Google's certificate private key, you can pretend to be Google. It's undetectable from the user's perspective. I think we should trust Google to keep their private keys safe, although it would help a lot if the published in general terms how they accomplish this.

The signing key for Gmail's certificate is a 1024-bit RSA key. That key size is simply not safe against an attacker like the NSA today, so we may as well assume they have the private key even if Google didn't voluntarily give it to them.

But while the signing key may allow them to impersonate Google in some circumstances, it doesn't really help decrypting passively recorded TLS traffic to the real Google. For that, they would need to break the ECDH key exchange, and if Google uses reasonable elliptic curve parameters, that's presumably much harder than factoring a 1024-bit RSA modulus, at least with known cryptanalytic techniques.

Google is currently working on upgrading their certificates so in the future it will be better: http://googleonlinesecurity.blogspot.com.au/2013/05/changes-...

"I think we should trust Google to keep their private keys safe, although it would help a lot if the published in general terms how they accomplish this."

Really, I would think it would be easy for the NSA, etc to get an operative inside Google, FB etc and steal these. Intelligence organizations are very good at this after all..

See here for why it would be detectable (for Google, at least): https://news.ycombinator.com/item?id=5843525

>How are they getting the DH keys without cooperation from at least one of the SSL endpoints involved?

One possibility is to actually compute discrete logarithms.

Does anyone know what elliptic curve parameters Gmail uses for key exchange? If the parameters are large, it is not feasible to break discrete logs using known methods, but while I'm usually wary of claims that the NSA is miles ahead of the academic research community, I could perhaps believe they have faster algorithms for e.g. some NIST curves.

Forward secrecy ensures that even if the private key is compromised at some point, one can't decrypt passively captured traffic.

What's a 'Diffie-Hellman key'?

"Forward secret HTTPS is now live for Gmail and many other Google HTTPS services(*), like SSL Search, Docs and Google+."

http://googleonlinesecurity.blogspot.com.au/2011/11/protecti...

Even without keys, the metadata from the packet headers and traffic analysis can be quite useful.

Could you link to tptacek's comments you're referring to?

It's gone.

> Could you link to tptacek's comments you're referring to?

https://news.ycombinator.com/item?id=5842915

I was being a bit devious. I am just so tired of tptacek dismissing stuff I say with asinine arguments and then watching my comment get downvoted to hell.

SSL broken by design:

http://cryptome.org/0005/ssl-broken.htm

If you hold the theory that the traffic is being intercepted and the parties have compromised the TLS keys: The test for complicity is obvious: failing to rotate out the TLS keys, failure to HSTS, and failure to switch to EDH ciphersuites everywhere.

These are all moderately 'cheap' steps if you believe you're being compromised in this manner.

Indeed, I'm highly inclined to defer to tptacek's experience here.

It has been well known that they already do the beam splitting portion, so it's really just up to the keys.

If anyone's not familiar, information about that began to leak in 2006.

http://en.wikipedia.org/wiki/Room_641A

Ok so they split and copy all the packets, nobody else is concerned with the complexity of tagging, filtering, rebuilding and contextualizing this conceptual volume of packet data?

Beam splitters are not enough, they would need something to interpret this traffic.

Something is missing here.

Like the huge number crunching center in utah?

Then you just process basic metadata. Size, IP source, destination, timing, and statistical analysis of the binary. Assuming that they have ways of converting IP to an identity that information alone would be hugely revealing. In fact basic metadata is what they have admitted to recording.

That's why IMHO secret sharing[1] algorithms are so important

We store only parity of data in one data center, and some in another on a different continent. Any data intercepted or lost does not damage the integrity of the whole, plus this makes ISP can not discriminate raw binary data.

[1] http://en.wikipedia.org/wiki/Secret_sharing, invented by Adi Shamir, the S of RSA

Reply on news.ycombinator.com