4 ms·

I think the article is saying that the implicated companies hand over their private keys.

by toiys 13y ago

kalmi10 13y ago
I 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 ago
  Lots 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 ago
    In 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 ago
    An 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 ago
  Perfect 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 ago
    Sure, but that's an active attack.

I think the article is saying that the implicated companies hand over their private keys.

by toiys 13y ago

I think the article is saying that the implicated companies hand over their private keys.

I 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 ago
Lots 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 ago
  In 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 ago
  An 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 ago
Perfect 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 ago
  Sure, but that's an active attack.