At Conformal, we keep up with the most secure cryptography technologies available and implement these technologies into our products and services whenever possible. However, we consider ourselves the minority in this practice, with most other sites only offering the bare minimum in terms of security. Amid the recent PRISM leaks, more and more attention has been drawn towards mass acceptance of one such technology, known as Perfect Forward Secrecy (hereforth referred to as PFS). This blog post will cover how HTTPS without PFS fails to protect today’s communication against tomorrow’s attacks, how PFS is able to prevent against these attacks, and the current state of PFS on the web and Conformal’s servers.
HTTPS (HTTP over SSL) is used today to secure everything from social networking to shopping to online banking. However, as with many issues, the devil is in the details. Most sites today enabling HTTPS perform the key exchange using RSA. When user initiates a connection to an HTTPS-enabled server, a series of steps must take place before an encrypted connection is established for communication. When PFS is not used, this handshaking (done through TLS) results in a client browser sending the remote server an encryption key for that session sent encrypted using the remote server’s public key. It is here lies the weakness, as the shared key for every connection from every client can be decrypted with the same private key.
For the sake of argument, let’s say that all connections between a client browser and a server are sniffed and recorded indefinitely. This could be done by any amateur malicious hacker, or by a more enabled body such as the NSA. If the server’s private key ever falls into the wrong hands, every recorded connection is now trivially decryptable. It is also possible for an organization to be strong armed into providing — or even willfully provide — the NSA with a copy of this no-longer-private key. Under this situation, the NSA would be capable of passively spying on every HTTPS connection in real time. In this way, the server’s private key acts as a sort of master key. If anyone has possession of this key, no encrypted connection can be considered secure.
PFS fixes this situation by ensuring that a session key can not be determined if any of the private keys are compromised. When PFS is used, the key exchange is performed slightly differently by having the server choose a temporary encryption key, rather than using the private “master” key. Even if this private key is compromised and a third party is passively observing or logging this handshake, the session key can not be determined. Without this session key, none of the encrypted traffic between a client browser and remote server can be decrypted.
Unfortunately for everyone, very few HTTPS sites today implement PFS. At the time of this writing, only three domains the author frequents enable PFS (implemented with the ECDHE-RSA or DHE-RSA key exchange protocols). Given the recent news concerning the NSA, it is no surprise that much more attention has been drawn towards the public’s awareness of PFS and seeing its widespread adoption. As a result, more and more sites appear to be adopting PFS, and that is a very good thing.
There may be a variety of reasons why most websites choose to not implement PFS. They may have not heard of it. Their TLS implementation may not support it. A more tin foil hat possibility may be that they have been asked at the request of the NSA to not implement PFS as it would make passively monitoring all encrypted traffic impossible. To those administrators who have seen the news and have implemented PFS as a response, we salute you. To all other sites who continue to refuse to protect their users with PFS, Conformal has revoked your internet gold star.
However, it’s now time for some gloating. As mentioned at the beginning of this post, Conformal takes pride in using the most advanced security technologies and making these available for our users. Conformal has always had PFS enabled on all Conformal and Cyphertite servers, ever since March 2012 when our servers were reconfigured from apache to nginx. We chose to implement this technology, not out of a knee-jerk reaction to a government leak, but because we are passionate about cryptography and wish to provide all our users with the highest level of security available. We always keep up with the latest news out of the security industry, and you can be assured that whenever you use our products, we have done our homework and are doing all we can to keep you safe online.