Perfect Forward Secrecy – CompTIA Security+ SY0-401: 6.1

| September 21, 2014 | 0 Comments


When a web server uses a single private key to encrypt all communication, then all communication can potentially be decrypted afterwards with this single bit of data. In this video, you’ll learn how perfect forward secrecy can be used to create encryption keys dynamically for every encrypted session.

<< Previous Video: Elliptic Curve and Quantum CryptographyNext: WEP vs. WPA >>


When you want to encrypt data sent from a browser to a web server, we commonly use SSL, or what’s now called TLS, to perform that encryption. We’re doing this by exchanging a session key between the client and the web server. And that session key is encrypted as it’s sent over the network with a key pair– what’s called an RSA key pair, which consists of a private key and a public key on the server.

Since every session key is encrypted with this public and private RSA key pair, if you somehow gain access to that RSA private key, you can then capture every bit of traffic across all sessions going to the web server. And then afterwards, you can decrypt all of the data made from every single session that was encrypted to that web server. This is obviously a single point of failure for every bit of website encryption. Once somebody gains access to the private key, they effectively also gain access to view all of your encrypted communications.

If you wanted to see what type of key pair was being used for this key exchange, you can look at the details. This is from my browser from JP Morgan Chase. And you can see the to that web server down at the bottom, it says my connection is encrypted with 128-bit encryption. It’s using RC 4, 128 with SHA-1 for message authentication and RSA as the key exchange mechanism. That tells us that RSA is what we’re using for that public private key pair on that particular web server.

To get around this problem of having one private key that can then decrypt everything going to your web server, you want to use something like Perfect Forward Secrecy or PFS. This changes the way that the key exchange operates. It does not use the private RSA key that might be on your web server and instead uses elliptic curve or perhaps Diffie-Hellman keys. And these are ephemeral keys that are used just once and then never used again.

This means that even if somebody did collect all of the data going to your web server and they did have access to the private key of that RSA key pair, they would still not be able to decrypt this information, because every session is using a completely different private key to make this symmetric key exchange. As you might imagine, this Perfect Forward Secrecy process or PFS does require additional resources and computing power on your servers. That’s why not every device out there is going to be using PFS, but we’re starting to see more and more web servers take advantage of it.

Another reason people may not want to implement Perfect Forward Secrecy is that not every browser understands how to encrypt information to a web server using PFS. And if you’re very concerned about having the largest number of people access your site securely, this may not be the right encryption method for you to use, at least not at this time. One website that is using this PFS method of transferring the keys is the Professor Messer website.

And if we look at the encryption details for my server, you can see that it says the connection is encrypted and authenticated using AES 128 GCM and uses elliptical curve Diffie-Hellman ephemeral RSA as the key Exchange mechanism. This means that it’s using this PFS, or Perfect Forward Secrecy, to be able to have a different method of exchanging that symmetric key with every single session to the Professor Messer website.

Tags: , , , , , , ,

Category: CompTIA Security+ SY0-401

X