During an SSL handshake, the client generates a key for encrypting the session traffic and sends it to the server after encrypting it with the server's public key, which is available in the server's SSL certificate. The server then decrypts the session key chosen by the client with its secret private key and starts using it. This is known as the key agreement, where the client and server agree on a shared key.
If non-PFS key-agreement protocols are used, an attacker who learns the server's private key by brute force or other means can use it to decrypt the shared keys for any sessions captured in the past. In this configuration, the server's private key is actually a master key for all previous communications.
PFS key-agreement protocols like ECDHE mitigate this master key vulnerability and force attackers to break separate private keys for every captured session if they want to learn their content, making the mass decryption of SSL traffic through brute force attacks a lot less practical.
Client-side support for key-agreement protocols with PFS is very good across the board, said Ivan Ristic, director of application security research at security firm Qualys, which runs the SSL Labs and SSL Pulse projects. Clients that don't support this type of key exchange are likely very old and the amount of traffic they account for is small, he said.
Support for this feature on the server side is not as widespread. Forty-two percent of websites surveyed by SSL Pulse support some PFS cipher suites, but only around 3.7 percent actually use them with modern browsers.
According to Ristic, PFS makes passive attacks like decrypting a large amount of captured traffic much harder, but it doesn't protect against active attacks. An attacker with access to the server's private key and its SSL certificate could potentially launch man-in-the-middle attacks to impersonate the website to clients and intercept their data in real time.
Google revoked all of its 1024-bit certificates, but some browsers can be blocked by attackers from checking whether certificates have been revoked, and past research revealed that many non-browser applications don't check for certificate revocation at all.
However, in addition to using PFS, Google probably used short-lived private keys limiting their potential value for man-in-the-middle attacks.
The company's new certificates with 2048-bit keys will expire in four months and will be changed, which is probably what the company used to do with its 1024-bit certificates too, Ristic said. "In my experience, Google has had the best SSL configuration for some time now."
The company is able to change public-private key pairs frequently because it operates its own intermediate CA called Google Internet Authority and can use it to issue new certificates to itself.
"The HSM (hardware security module) that contained our old, 1024-bit, intermediate certificate has served us well," Dulay said. "Its final duty after all outstanding certificates were revoked, was to be carefully destroyed."
"With the demolition of the HSM and revocation of the old certificates, Google Internet Authority G2 will issue 2048-bit certificates for Google web sites and properties going forward," he said.