[schtev]

Or just throw away the lock entirely, given that Google is in bed with the NSA.

[mpyne]

Google is the only major player even employing perfect forward secrecy; hardly a case of a company trying to get extra-cozy with the NSA.

[yk]

Perfect forward secrecy would prevent some attacks against Google, as does certificate pinning in Chrome. But if the NSA got somehow Google's secret key, they can still MITM a SSL connection. It just means, that they actually need Google's secret key, instead of using a CA under their control. ( And they need this key before they can MITM any connection.)

And the entire secure connection stuff is broken, if the NSA just obtains a FISA warrant for your GMail account. ( Or compromises the Google servers directly.)

[anonchl]

> they actually need Google's secret key, instead of using a CA under their control

Note that Google runs their own CA (signed by Equifax's Root CA) and, thus, issues their own certificates.

The way things are going, I see no reason why the NSA could not, with a FISA warrant, simply order Google to:

1. provide them with a copy of Google's CA's private key; or, 2. issue the NSA a certificate valid for *.{every-google-domain}.com.

Maybe they can.

Maybe they have.

[commandar]

>But if the NSA got somehow Google's secret key, they can still MITM a SSL connection.

Security isn't my field at all, but I'd gotten the impression from HN that PFS is meant to protect against just this scenario. Am I mistaken?

[bradleyjg]

What PFS will protect against in this scanario is decrypting SSL sessions whose cyphertexts were captured before the attacker had access to the private key. It doesn't protect against (any) man-in-the-middle attacks.

[daeken]

Before or after they have access to the private key, so long as an active MITM is not performed. In essence, PFS makes it such that no matter what information you have about the server's configuration, passive sniffing of data is not enough to compromise a connection's confidentiality.