Akamai Diversity

The Akamai Blog

Looking forward to Forward Secrecy

Akamai is constantly looking for ways to improve the security of our platform and protect our clients' traffic. We're currently looking into an encryption mechanism called Perfect Forward Secrecy, or simply Forward Secrecy. We prefer to use the term "Forward Secrecy" because nothing in security is perfect and we'd rather not imply that it could be. Akamai plans to include Forward Secrecy as a capability our customers can start using in the first half of 2014.

If you're connecting to a web site securely, you're probably using an encrypted connection over HTTPS, which uses SSL to encrypt traffic between the browser and the servers you're connecting to. The browser and the server negotiate the level of encryption to be used between them as part of the initial connection. This process includes the creation of a session key that is used to encrypt all further communications and deleted afterward. However this key needs to be communicated between server and browser, which is done using public key encryption and encrypting the session key with the private portion of the SSL key of the server. 

The weakness in this method of passing the session key between the server and the browser is that the entire communication stream can be decrypted if the stream is captured and the key used to encrypt the session key is known. While it's extremely useful to be able to use this capability with some network devices that require access to the traffic, such as Intrusion Detection Systems (IDS) and Web Application Firewalls (WAF), it has weaknesses. For example, it is possible for an attacker to capture the traffic and crack the private key offline, thereby gaining access to the session key and the entire encrypted communication. The ability to crack the private key once seemed to be an extremely time consuming process, but the use of graphics cards as fast cracking processors, the invention of quantum computing and revelation of weaknesses in the randomization process of some encryption techniques make the cracking of private keys much less time consuming than it used to be. And if enough computing power is applied, even the strongest keys can eventually be undone. Finally, the owner of the encrypting server can be forced to give up the private key, as is the case when a subpoena or other legal document is served to a service provider.

Which is where Forward Secrecy comes into play. While the communication of the session key is normally done using the private key of the server, when Forward Secrecy is involved, the session key is communicated using a temporary, or ephemeral, encryption key that is discarded once the session is over. This means that rather than having to crack one key which grants access to all communication encrypted with that key, an attacker would have to crack each key for each session individually, greatly increasing the time required to gain access to the communications of secure traffic.

So why isn't Forward Secrecy used everywhere?  There are two main problems with this solution. The first is that it is only supported by two algorithms: Diffie-Hellman (DHE) and (ECDHE). These algorithms aren't supported by all browsers, though the latest versions of all browsers do support them. The second issue is that these algorithms are currently slower and require 10-15% more computing power in order to use. This may not sound like a lot of additional CPU usage, but for any high capacity server, 10-15% is a huge hit to be able to support.

Akamai supports our clients' in their efforts to secure communication with their customers.  As such, we are constantly looking for ways to improve their security, with Forward Secrecy one way to provide greater security. Despite the name, nothing in security is ever 'perfect', but Forward Secrecy greatly increases the level security over normal SSL session key communications. Akamai will continue to research additional ways to secure all the traffic for which we are responsible.

For more information on Perfect Forward Secrecy, read the PFS Wikipedia page or Ivan Ristic's SSL Labs posting.

Additional resources:








Martin McKeay is a Senior Security Evangelist at Akamai