Ugh, this keeps coming up. No amount of cooperation from Certificate Authorities will enable passive attacks on SSL.

All the CA does is cryptographically certify "this is the public key that the Company (eg. Google) gave me"; they never see the corresponding private key.

Cooperation from the CA might give the NSA their own certificates for Google, which would allow for an active man-in-the-middle attack. Certificate pinning would defeat that, and doing that on the fly in the Internet at large would be a serious undertaking.

But if they want to decrypt traffic passively and they don't know about serious SSL vulnerabilities, they would have to have Google's private key. And with Perfect Forward Secrecy, even that is not sufficient. (PFS requires an active attack because the session key can only be determined if you're actually one of the two doing the handshake, or you know how to factor very large numbers.)

1) Generating certificates on the fly for arbitrary domains has been the usual operating mode for transparent proxies for at least 8 years. 2) There have been many public SSL vulnerabilities in the last year. To think that there might be some non-public ones is not a stretch. 3) If anyone can factor very large numbers, it is the NSA. The move to ECC for Suite B has been interpreted to imply this may be becoming more feasible.

Large-scale active attacks on SSL are infeasible, as many applications (Chrome included) support certificate pinning.

Furthermore, this would be easily reproducible evidence that they are actively intercepting (and proxying) traffic. Never happen.

> No amount of cooperation from Certificate Authorities will enable passive attacks on SSL

Actually, it's quite common for CAs to do the site admins a favor and generate the keypair for them. The admin then downloads the private key and installs it on his server.

On TLS connections where the client and server do not negotiate the use of Ephemeral Diffie-Hellman (EC)DHE (sometimes called EDH), then the CA could have retained the private key data which could be used to decrypt the packet capture after-the-fact.

Google should be applauded for configuring their servers to prefer (EC)DHE on their TLS services. It also means they can fight a law enforcement subpoena for their private key.

The attack is to generate a certificate, sig. it themselves as valid, and then man in the middle the target. it's not about decrypting somebody else's session, it's about creating their own, seemingly valid one.

What I think you're driving at is what this device (and others like it already do) http://www.nextgigsystems.com/netronome/ssl_inspector_SI-800.... However, you must be sitting in between the client and server and inject into the exchange (be a proxy). You can't just listen to both sides and reconstruct it later. Well, that is if you believe the NSA has not straight-up cracked SSL -- which I don't believe it has above 128-bit keys. Their cpu cycles are better used elsewhere, plus they have so much unencrypted data to analyze. But the race continues...

I would imagine the tech used in the device you linked to has been in use for quite some time. Nothing stated in the Rackspace or other ISPs posts says anything about the routers in place at these facilities. They're all quite careful to say how secure the customer's "stored data" is safe on the "servers" - nothing is said about data flows through routers.

I note there's been no statements - suspiciously scripted or not - from the likes of Juniper, EMC, HP, Dell, Cisco...

The social media company presumably-NSA-supplied denial script says "no direct access to servers".[1] I wonder just how few bits of networking gear (or switch OSs) you'd need to root - gear that sits between the SSL termination and the servers - to not even need to ask for "direct access"?

[1] In fairness - perhaps that turn-of-phrase only appeared in every CEO denial because it was a direct quite from the WaPo article.

Yes, and his answer is also carefully crafted to talk about dedicated servers, not Rackspace's 'cloud' service.

How so? It says "All Customer Data" and across all their products.