What is Perfect Forward Secrecy and its impact on SSL (HTTPS)

Actually I was writing a usual tutorial article for getting SSL VPN configured for clients to login using their key pairs. I was doing a little bit of research to make that article more accurate while I explain its working. And during that research I stumbled upon one interesting fact about the way we communicate using SSL. Hence this article is the result of whatever I found.

The main reason am writing this is because it has a major security impact on the way we communicate today over the internet.

Millions of dollars are transferred on a daily basis using SSL, thinking its the best secure protocol out there. And yes it is the best out there(thanks to mathematicians and crypto experts! And yeah thanks to Netscape!). However there is a major flaw or I must say a flaw in the way it is implemented by most of the major players in the industry.

Before getting into the details of what is it and how it matters, I will explain the way SSL works. Please note the fact that I will not be including the complete details regarding SSL here in this description because our topic of interest is not SSL. However I have tried my level best to explain the working of SSL in other series of articles (Please not the fact that I have not included mathematical and encryption details in those too, as I am not capable enough to comprehend them.)

Read: How SSL (Secure Socket Layer Works)

SSL Working involves a series of steps taken by both the server and the client during their initial handshake. As the client is the one who iniates the connection by sending an HTTP request to a SSL enabled web server. The first message send by the client is a HELLO message.

The below shown diagram depicts the basic working.

As you can see from the above figure, the initial message send is by the client. This message is called the hello message and there is also one hello message send by the server. Hello messages are similar in nature.

The server also sends the server certificate along with the public key. The client sends the premaster secret encrypted with the server's public key. This premaster secret is used to construct the master secret.

Anything encrypted with the server's public key can be decrypted by using the server's private key.

Also another important fact to note here is that...

The premaster secret send by the client will be used to make a master secret. Apart from the premaster secret, the random values send by both the server and the client is also used in the making of the master secret. Please remember the fact that nothing is encrypted when the random values were sent.

How this concerns security in SSL ?

A single point of weakness in any architecture is always a problem and requires speculation. The single point of weakness in SSL in the above explained method of handshake is the Server's private key.

Yeah there is always an argument that the server's private key is always kept secure inside the server. And no body has access to this private key. Yeah agreed.

But imagine if the ISP between you and the server is recording all the data transfer that is occurring. I don't think any ISP does that. But if they do they can decrypt the entire data transmitted between you and the server.

If the ISP has the complete data transferred stored, they can think of reading that data at a later point of time when the server's private key becomes available to them.

If you remember, during the revelations regarding PRISM, it was revealed that they are recording all internet communications. And if they can store internet traffic of about 10 years, they can easily decrypt and open the encrypted data when the server's private key becomes available.

Fortunately there is a solution to this problem. But unfortunately not all of them are using this solution. In fact i must say the main problem is the lack of implementation of the solution.

The solution to this problem in cryptographic term is called as Forward Secrecy or PFS (Perfect Forward Secrecy.)

What is PFS or Perfect Forward Secrecy?

Perfect Forward secrecy works by the idea that a compromise of the private key should not compromise session key.

Session keys are also used in the previously seen method of SSL. But the problem with that method is that the components that make the session key was encrypted using the server's private key.

Session key must be unique for each SSL session and must be derived separate. Also the session key's must be destroyed by both the ends once the communication is complete. So even if somebody has access to the server's private key, they cannot obtain the session key and hence cannot decrypt the data.

The Algorithm that helps to achieve this kind of perfect forward secrecy is called as "Diffie–Hellman key exchange". Its a pretty old algorithm used to derive a shared secret.

The most important aspect of Diffie–Hellman key exchange is the fact that the shared secret derived by the algorithm is never transmitted over the wire. Both the server and the client calculates the shared secret by themselves, and the resulting value (shared secret which will be session key) will be same on both the sides. Hence this shared secret can be used for symmetric encryption (where same key is used for both encrypting and decrypting data.).

As both the server and the client calculates the shared secret (session key), and their end results are the same, they will use it for encrypting the real data transfer(no shared secret is transmitted over the wire).

Now this is the real magic of mathematics involved in Diffie–Hellman key exchange method. I will give you a slight idea of what i understood about the Diffie–Hellman key exchange (describing it with its full mathematical detail is beyond my reach.)

• Both the end points create a public private key pair and share public keys with each other.
• Each end point has got the public key of the other end point, also each end point has their own private keys.
• Each end point calculates a shared secret with the help of their private key and the other end point's public key.
• The magic of mathematics here is that the shared secret calculated by this method is identical at bot the ends and hence no sharing or transmitting of shared secret is done.

If you really interested in understanding how Diffie–Hellman key exchange works then i would recommend reading the below PDF document from cisco.

How does Diffie–Hellman key exchange work

Please note the fact that when SSL uses DH (Diffie–Hellman key exchange), it is only used for deriving a common shared secret (session keys), the authentication of the server is done by the server private key. The use of Diffie–Hellman key exchange in SSL is to use a separate method to derive session key independent from the server's private key.

If you want to know whether an SSL connection that you are using is having perfect forward secrecy in place, then you need to check what algorithm is used to derive the shared secret. If you pay attention to the diagram i have shown in the beginning of this article, the initial hello message send by the client and the response hello message returned by the server includes the SSL versions and cipher suits they support.

Hence if anyone who is interested in enabling perfect forward secrecy on their HTTPS servers need to use and support ephemeral Diffie-Hellman (DHE) or the elliptic-curve variant (ECDHE). Also these algorithm's must be given higher priority on the server side in their configuration. The server configuration can be altered to give higher priority to different algorithms. 

In short the order in which the cipher suits supported by the server is defined plays a major role during the selection. This is because even the client's (Web Browser's) must also support them.

Last month the famous social networking site Twitter enabled perfect forward secrecy on their servers. Shown below is an excerpt from the official twitter blog post dated on Friday, November 22, 2013 by Jacob Hoffman-Andrews.

You can read the entire twitter blog post regarding their implementation by accessing the below link.

Read: Twitter implements Perfect Forward Secrecy

Note: Google implemented this in 2011 itself. Read: Google official blog post regarding their forward secrecy implementation

The main reason i referred to the latest twitter implementation is because still many of the high profile web sites are not using this secure method called perfect forward secrecy for HTTPS.

While accessing any HTTPs enabled websites, you can easily see the cipher suite used by selecting the LOCK icon beside the URL area.

The above shown pic is from a firefox browser. Inside the "more information" tab, you will be able to see the current cipher suite under use. You will be able to see something like the below.

Connection Encrypted: High-grade Encryption (TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, 128 bit Keys)

Any HTTPS website that uses Diffie-Hellman (DHE) or the elliptic-curve variant (ECDHE) in their cipher suite is having a perfect forward secrecy enabled. Hence if you see something like TLS_ECDHE_ECDSA, its using PFS.

        Please note the fact that you need to have your browser updated to the latest version, as older browser versions does not support this. Some Exceptional worst case is with Internet Explorer.

Some of the sites which are very highly used and is not currently implementing forward secrecy are mentioned below.

The above mentioned are only few among the elite club, forget about the low profile web sites.

Web browsers play a major role in the implementation of Perfect Forward Secrecy. Be rest assured if you are using a latest version of either Firefox or chrome.

How to configure Perfect Forward Secrecy for a web server?

Well the configuration differs slightly on each web server package. We will see how to enable this on Apache and Nginx. Nginx has this added advantage that if you are using SSL on it, it by default enforces PFS (Perfect Forward Secrecy), by keeping the DH and Elliptical DH at a higher priority than other ciphers. However, please remember the fact that any web server that employs DH for PFS then there will be a slight performance degradation as the web server has to do a little bit more math.

ssl_prefer_server_ciphers on;
ssl_protocols SSLv3 TLSv1;
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:RC4-SHA;

The above shown nginx configuration parameters are quite self explanatory. The only main thing that you need to note here is the order in which the cipher is mentioned.

The first one is given the higher priority. If the browser supports it, then that will be used.

As told before, enabling this can slow the SSL requests slightly. But its better to have this enabled if the website is doing some critical information exchange.

Even in apache, the configuration is exactly the same with only the parameter name difference. The apache configuration looks like the one shown below.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4EECDHEDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

Some note worthy points about PFS (Perfect Forward Secracy)

• Due to the performance issues involved in implementing DH most of the sites normally does not enable this feature by default. However a slight modification on the server side can make the communication more secure.
• ECDH is comparatively faster than DHE. And another added advantage is that almost all latest browser versions do support this cipher suite. 
• Please note the fact that the main security behind perfect forward secrecy is the session keys and distroying it once the session ends.