3 ms·

Although even with PFS, cracking Google's private key would still give them access to every future encrypted session, until the key changed. So PFS is no panace

by graue 13y ago

Although even with PFS, cracking Google's private key would still give them access to every future encrypted session, until the key changed. So PFS is no panacea here.

spicyj 13y ago
If I understand properly, having Google's private key only allows you to do MITM attacks, not to passively decrypt traffic using PFS algorithms.
- graue 13y ago
  Absolutely. This is why PFS protects past sessions, because you can try to decrypt the past, but you can't MITM the past. But do you think the slightly harder task of running MITM attacks (as opposed to simply siphoning off a copy of the data as it passes) would thwart an entity like the NSA? I really doubt it. PFS or not, a leaked private key means game over for all data transferred after the leak and until that key is replaced. And that's my point, the reason I made the statement you're replying to: it would still be well worth the NSA's time to crack Google's private key, and PFS doesn't somehow make that scenario not bad. Your statement is correct, but, I argue, not terribly relevant. (Sorry if this post sounds confused; it's late.)
  - mortehu 13y ago
    > But do you think the slightly harder task of running MITM attacks (as opposed to simply siphoning off a copy of the data as it passes) would thwart an entity like the NSA? MITM attacks have the disadvantage that they can be noticed by communicating the session key through a second, more secure, channel, for example one using a client certificate.
bigiain 13y ago
Isn't it a little more complicated than that? With PFS, the webserver and the browser (yeah, oversimplifying here) each generate a random number and "create" a temporary session key without revealing enough about their individual random numbers to an eavesdropper. So as well as Google's private key, the attacker also needs the "agreed upon ephemeral key" for each session if they want to passively snoop. (And if they're deeply enough into Google's infrastructure to see and archive those, then don't need to decrypt SSL connections - they can just syphon the cleartext out from inside the SSL termination). (Note: I'm still trying to educate myself here. I fear I may be not fully understanding the subtleties and differences between DH & DHE, and when that "E" means "ephemeral" and whether it also sometimes means "elliptic"…)

by graue 13y ago

Although even with PFS, cracking Google's private key would still give them access to every future encrypted session, until the key changed. So PFS is no panacea here.

spicyj 13y ago

If I understand properly, having Google's private key only allows you to do MITM attacks, not to passively decrypt traffic using PFS algorithms.

graue 13y ago
Absolutely. This is why PFS protects past sessions, because you can try to decrypt the past, but you can't MITM the past. But do you think the slightly harder task of running MITM attacks (as opposed to simply siphoning off a copy of the data as it passes) would thwart an entity like the NSA? I really doubt it. PFS or not, a leaked private key means game over for all data transferred after the leak and until that key is replaced. And that's my point, the reason I made the statement you're replying to: it would still be well worth the NSA's time to crack Google's private key, and PFS doesn't somehow make that scenario not bad. Your statement is correct, but, I argue, not terribly relevant. (Sorry if this post sounds confused; it's late.)
- mortehu 13y ago
  > But do you think the slightly harder task of running MITM attacks (as opposed to simply siphoning off a copy of the data as it passes) would thwart an entity like the NSA? MITM attacks have the disadvantage that they can be noticed by communicating the session key through a second, more secure, channel, for example one using a client certificate.

bigiain 13y ago

Isn't it a little more complicated than that? With PFS, the webserver and the browser (yeah, oversimplifying here) each generate a random number and "create" a temporary session key without revealing enough about their individual random numbers to an eavesdropper. So as well as Google's private key, the attacker also needs the "agreed upon ephemeral key" for each session if they want to passively snoop. (And if they're deeply enough into Google's infrastructure to see and archive those, then don't need to decrypt SSL connections - they can just syphon the cleartext out from inside the SSL termination). (Note: I'm still trying to educate myself here. I fear I may be not fully understanding the subtleties and differences between DH & DHE, and when that "E" means "ephemeral" and whether it also sometimes means "elliptic"…)