Google Protects Its Current HTTPS Traffic Against Future Attacks

HTTPS-enabled Google services now implement a special encryption technique to mitigate future key recovery attacks

Google has modified the encryption method used by its HTTPS-enabled services including Gmail, Docs and Google+, in order to prevent current traffic from being decrypted in the future when technological advances make this possible.

The majority of today's HTTPS implementations use a private key known only by the domain owner to generate session keys that are subsequently used to encrypt traffic between the servers and their clients.

This approach exposes the connections to so-called retrospective decryption attacks. "In ten years time, when computers are much faster, an adversary could break the server private key and retrospectively decrypt today's email traffic," explained Adam Langley, a member of Google's security team, in a blog post.

In order to mitigate this relatively low, but real security risk, Google has implemented an encryption property known as forward secrecy, which involves using different private keys to encrypt sessions and deleting them after a period of time.

In this way, an attacker who manages to break or steal a single key won't be able to recover a significant quantity of email traffic that spans months of activity, Langley said. In fact, he pointed out that not even the server admin will be able to decrypt HTTPS traffic retroactively.

Because SSL wasn't designed to support key exchange mechanisms capable of forward secrecy by default, the Google engineers had to design an extension for the popular OpenSSL toolkit. This was integrated into OpenSSL 1.0.1, which has yet to be released as a stable version.

The new Google HTTPS implementation uses ECDHE_RSA for key exchange and the RC4_128 cipher for encryption. Unfortunately, this combination is only supported in Firefox and Chrome at the moment, which means that HTTPS connections on Internet Explorer will not benefit from the added security.

This isn't necessarily a problem with Internet Explorer, which does support a combination of EDH (Ephemeral Diffie--Hellman) key exchange and RC4. EDH also provides forward secrecy, but Google chose ECDHE (Elliptic curve Diffie--Hellman) instead for performance reasons.

The company plans to add support for IE in the future and hopes that its example will encourage other service providers that use HTTPS to implement forward secrecy so that one day it can become the norm for online traffic encryption.

New! Download the State of Cybercrime 2017 report