Perfect Forward Secrecy
When thinking about the possibilities and problems with cryptography when it comes to protecting from a large and resourceful eavesdropping organization such as FRA i found myself asking this question: If someone passively snoops encrypted web communication, is it possible to decrypt the information at a later date, if the secret key of the website somehow gets in the hands of the eavesdropper?
Why is this important? Well, if you have a scenario when for example a government agency has the ability to eavesdrop on and store vast amounts of data it might come to a situation when said agency gets really interested in decoding some of the encrypted information that is has snooped. If you are a government agency it might be enough to send a nasty letter to for example a webmail or social networking service demanding the key, or even break into the hosting facility that holds the secret key and obtain it, legally or illegally.
Anyway, back to my question. After some research I have found the somewhat dissatisfying answer is most of the time, stored encrypted traffic can be decrypted if the key is obtained. There is however a technique that effectively prevents such a scenario called Perfect Forward Secrecy. It is available when using the the DHE key exchange protocol, which is part of some of the cipher suites that can be used with TLS, the protocol used when connecting to a website with an address starting with https.
DHE stands for Diffie-Hellman key exchange with Ephemeral parameters, a method for a server and a client (in this case a web browser) to find a common session key that is used to encrypt the actual data without ever sending the actual session key in clear text. The key, as well as the Diffie-Hellman parameters used by the client and server to calculate the key is (hopefully) never stored on disk, but created for each connection (or, in the case of session caching, each couple of connections between the same server and client) and then discarded. The long term secret key used to authenticate the server and hopefully prevent man-in-the-middle attacks can not be used to re-create the session key even if it is known by an attacker.
To be able to use DHE to set up the encrypted connection, both web server and web browser need to support it. All modern web browsers that I have tested supports it, but for some reason many web servers doesn’t. Why? I’m not really sure, but I think that it might have to do with several factors. It it requires a bit more server resources to set up a DHE key exchange than it does to set up a straight RSA one. Also, I think that many people making decisions about which cryptos to provide has too much confidence that a secret key will remain secret.
Anyway, if you want to test if your web browser supports Ephemeral Diffie-Hellman key exchange, feel free to visit my cryptography test page that I set up to try this out. If you want to avoid certificate warnings you might want to install the CACert root key in your web browser. It is as least as secure and well maintained as the other root certificates that are already bundled with your web browser or operating system.
Filed under Cryptography | Comment (0)