5 ms·
"All they would need for unfettered access to user data is the SSL/TLS private key file used to encrypt traffic." False, one can't passively mitm SSL when perf
by kalmi10 13y ago
"All they would need for unfettered access to user data is the SSL/TLS private key file used to encrypt traffic."
False, one can't passively mitm SSL when perfect-forward-secrecy is used.
I just checked, and google seems to be using it.
http://www.quora.com/SSL-Secure-Sockets-Layer/Is-it-ever-possible-to-decrypt-passively-sniffed-SSL-TLS-traffic/answer/Ian-Gallagher-2 http://www.quora.com/SSL-Secure-Sockets-Layer/Is-it-ever-pos...
- toiys 13y agoI think the article is saying that the implicated companies hand over their private keys.
- kalmi10 13y agoI understand that. The previously 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 against SSL if perfect forward secrecy is used. Google uses Diffie–Hellman key exchange which provides perfect forward secrecy. So... If I understand everything correctly, it should be impossible to decrypt passively captured SSL-encrypted communication to/from google.com.
- mayank 13y agoLots of fun things can happen if you control peering points. Putting on my tin foil hat for a minute: trivially place yourself in the middle. The client connects to you, you impersonate Google by spoofing their IP (which you can do becase you control the peering point and routing tables), and using their certificate. Connect to Google simultaneously, spoofing the client's IP. Use EDH to establish independent sessions to both the client and Google, with your (now essentially useless) perfect forward secrecy, MITM away. Edit: replying to the poster below, it doesn't have to be a passive attack, and I'm not sure what you mean about checksums. The scenario above would look exactly like normal Internet traffic. You're not mutating packets, you're sending entirely new ones.
- DavidSJ 13y agoIn that case it's not a passive attack. If the NSA was routinely actively mutating nearly all SSL traffic to Google, I'd expect someone might have eventually noticed that the TCP segments are received with a different checksum than with they were sent.
- kalmi10 13y agoAn attack like that would also mess up the flow of the data. Me in Europe ------200 ms------- MITM magic --1 ms-- Google For the attacker not to introduce huge extra latency, it would need to complete the handshake with Google almost instantly. Someone would eventually notice instantaneous TLS handshakes. Also 2 separate TLS connections would contribute to bufferbloat pretty badly, and someone would also eventually investigate that.
- reedlaw 13y agoPerfect forward secrecy only works if identities can be verified. If impostor certs for Google.com exist, you can't be sure you're talking with Google.com
- kalmi10 13y agoSure, but that's an active attack.
- fooey 13y agothey don't have to MITM SSL if they clone the traffic: "install beam splitters at peering points" then there are 2 endpoints that are decrypted separately
- zero_intp 13y agoThe name prism is not a coincidence.
- kalmi10 13y agoI would believe that, was it not for this: "I realized that the U.S. government loves the "PRISM" acronym. There are literally dozens of projects and applications named PRISM at the state and federal level, many with delightfully goofy logos." http://waxy.org/2013/06/these_arent_the_prisms_youre_looking_for/ http://waxy.org/2013/06/these_arent_the_prisms_youre_looking...;
- reedlaw 13y agoWhat if it's the trusted Root CAs who are giving state agencies copies of their signing keys thus allowing them to sign valid certificates to impersonate anyone?
- marshray 13y agoThat would likely work for targeted attacks against browsers other than Chrome (and maybe recent FF, I'm not sure) but not for large scale dragnet attacks.
- reedlaw 13y agoWhy wouldn't it affect Chrome if the Root CA is trusted by Chrome? According to http://www.chromium.org/Home/chromium-security/root-ca-policy http://www.chromium.org/Home/chromium-security/root-ca-polic... they use the underlying OS list except in the case of Linux in which they use Mozilla's list.
- jmesserly 13y agoChrome has certificate pinning, see http://blog.chromium.org/2011/06/new-chromium-security-features-june.html http://blog.chromium.org/2011/06/new-chromium-security-featu...: "In addition in Chromium 13, only a very small subset of CAs have the authority to vouch for Gmail (and the Google Accounts login page). This can protect against recent incidents where a CA has its authority abused, and generally protects against the proliferation of signing authority." (disclaimer: I work for Chrome but not on these features.)
- jd007 13y agoThat hinges on browser support for DHE for key exchange (or some other method that provides PFS, like the elliptic curve optimized ones), which is not supported on all browsers. Notably IE and older Chrome/FF, though this could've improved since last time I checked. But yes, if PFS key exchange is used in TLS then having the private key alone would not help with decrypting previously gathered packet data. In that case the only thing I can think of for NSA to read the data is if they successfully created (in secret of course) a practical quantum computer which then renders RSA and DHE (anything that relies on integer factorization or discrete logs for that matter) completely broken.