Google Looks at HTTPS Security

Monday, November 28, 2011 @ 05:11 PM gHale


Google modified the encryption method used by its HTTPS-enabled services including Gmail, Docs and Google+, in order to prevent current traffic from suffering issues in the future.

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

RELATED STORIES
Google Fixes Chrome Hole, Again
Vulnerability Leader: Google
Patched Adobe Still has Victims
Apple Closes iPhone, iPad holes

This approach exposes the connections to 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,” said Adam Langley, a member of Google’s security team.

In order to mitigate this relatively low, but real security risk, Google 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 not even the server admin will be able to decrypt HTTPS traffic retroactively.

Because the design of SSL was not to support key exchange mechanisms capable of forward secrecy by default, the Google engineers had to design an extension for the popular OpenSSL toolkit. They integrated it into OpenSSL 1.0.1, which has yet to release 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 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 its example will encourage other service providers that use HTTPS to implement forward secrecy so one day it can become the norm for online traffic encryption.



Leave a Reply

You must be logged in to post a comment.