We often do examples of cryptographic protocols using Alice and Bob, and we may tend to think of them as just two individuals. But in the real world, the environment is more often one of an individual communicating with a server and establishing secure communications. This usually involves both Diffie-Hellman and a public key method such as RSA. So how does this process process work in practice? I will present here a high-level conceptual view of the process that will help us understand the principles involved.
The ClientHello Message
Well, in general it starts with the individual. If I go to a Web site, either I may find that it creates a secure connection by default, or if it doesn’t, I have installed a browser plug-in called HTTPS Everywhere, from the Electronic Frontier Foundation, that will tell the server I prefer a secure connection if possible. I am still at the mercy of the web site since they need to have installed and configured the necessary certificate for a secure connection. But the starting point is me contacting the server (Amazon has not, to my knowledge, ever initiated a session by logging me in and then asking “Do I need anything today?” Though if they figure out how to do it I would not put it past them.) So when I initiate a connection, and try to make it secure, the first thing that happens is a negotiation over the cryptography. My browser will initially offer something like this:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
So, to start with it is trying to:
- establish a TLS (i.e. Transport Layer Security) connection
- using Diffie-Hellman Ephemeral (for the shared secret used for the session)
- combined with RSA (the public key protocol used to create the secure initial connection
- using Advanced Encryption Standard (AES) with 256 bits
- using Cipher Block Chaining (CBC)
- and using the Secure Hashing Algorithm (SHA)
This should, by the way, offer the strongest encryption my browser is capable of, but I don’t want to get into the negotiation of protocols right now. But I will note that protocol downgrade attacks like POODLE are one of the reasons that SSL has been deprecated in favor of TLS.
The ServerHello Message
The Server needs to respond, and that is the ServerHello message. This will either accept the proposed options from the client, or fail if they are not acceptable. In addition, the server will provide two key items: a certificate to authenticate the server which contains the public key of the server, and a random 32 byte number which will be used for the Diffie-Hellman key exchange. Note that all of this is still in the clear, as we are still negotiating for a secure connection.
Diffie-Hellman Key Exchange
Now we can start the process of establishing a secure connection by doing a Diffie-Hellman Key Exchange. The Client creates its own random number, which it encrypts using the public key of the server, which it got from the certificate the server sent in the ServerHello message. The server receives this and decrypts the message using its private key. So now the client has a random number it got from the server, and the server has a random number it got from the client. From this it easy to apply a Diffie-Hellman process to create a shared master key that will be used going forward. The handshake process therefor concludes with Change cipher spec messages which switch from the public key encryption enabled by the certificate to the symmetric Diffie-Hellman key just negotiated.
What Could Go Wrong?
This process is secure against eavesdropping, just as we saw in our first look at Diffie-Hellman. And the use of Public Key encryption to initiate the secure communication makes it safe as long as you are careful about the certificates. As noted in previous tutorials, man-in-the-middle is possible, but only by substituting a different certificate. In a corporate environment, at least in the U.S., if you use a company computer they may “intercept” communications by putting their server in between and establishing connection on both sides ( the client and the remote server), but if you are careful about inspecting your certificate you will at least know if this happens. Using your personal computer does not provide any justification for this, though, and standards like OCSP Stapling (see TLS/SSL Certificate Issues and Solutions for more on this) have been designed to make it very difficult to spoof certificates in any way.
But a couple of big problems still exist. First, control of the server may be lost due to malicious cracking, law enforcement, or any other reason. If that happens, any keys that have been employed might be obtained from the server, and then the communications could be decrypted. I might not care if the communications regarded my purchase of specialty teas from Amazon.com, but if they were sensitive e-mails I might be very concerned. The second issue would be if the messages were intercepted and stored for future decryption. We know that this is an arms race, and that encryption methods that look safe for now might become much less safe if there is a breakthrough in technology (e.g. quantum computing). It is known that the NSA has a facility built to store stuff it grabs from the Internet with an eye to being able to decrypt it in the future. That is what has sparked the interest in Forward Secrecy: my data may be secure now, but will it be secure in the future?
Forward Secrecy
This has also been discussed as Perfect Forward Secrecy, but I would argue that is a misnomer since it is not perfect protection. Indeed, the idea of this being a technological arms race is an argument that no perfect solution will ever be discovered since any improvement in encryption will at some point be matched by an improvement in decryption. And Forward Secrecy cannot protect against brute force decryption. If quantum computing makes all of your keys as strong as tissue paper, anything encrypted with those keys will now be an open book. Note however, that there is a developing field of quantum encryption, which looks at harnessing the power of quantum computing to protect your data and communications. As I said, this is an arms race.
What forward secrecy does is provide key protection, which it does by using new keys for every session. What this means in practice is that if someone got their hands on the key used when you wrote an e-mail on January 9th, it would be no help at all in dealing with your e-mail on January 10th. Neither would it help with any web browsing you did on January 9th since that would be a separate session from the e-mail. And because there is a new key used for each session, one requirement of Forward Secrecy is that keys would not be stored. They would be used within a session, then discarded. This does point out one potential weakness, however, which is that a user has to trust the server to follow the protocol in this respect, and I can imagine a service provider of some kind violating this due to sheer incompetence or because of a requirement from law enforcement. There is a reason so many countries insist that all e-mail providers locate servers within the country where the government can gets its hands on them.
One of the early adopters was Google. Adam Langley from the Security Team posted a notice on their Security Blog on November 22, 2011 called Protecting data for the long term with forward secrecy. In this short blog post he mentions that Google “support(s) forward secrecy using elliptic curve Diffie-Hellman”.
On November 22, 2013, Twitter announced in its blog under the heading Forward Secrecy at Twitter that they would also be using forward secrecy, and similarly said the following:
There are two main categories of Diffie-Hellman key exchange. Traditional Diffie-Hellman (DHE) depends on the hardness of the Discrete Logarithm Problem and uses significantly more CPU than RSA, the most common key exchange used in SSL. Elliptic Curve Diffie-Hellman (ECDHE) is only a little more expensive than RSA for an equivalent security level. Vincent Bernat (@vince2_) benchmarked ECDHE at a 15% overhead relative to RSA over 2048-bit keys. DHE, by comparison, used 310% more CPU than RSA.
Finally, Apple published a specification called App Transport Security that is now mandatory for all apps. It has several provisions, but one of them involves forward security. In an article from the SSL store there is a good description of this provision:
ATS also requires the use of TLS 1.2 and a cipher suite that provides forward secrecy. Developers will need to ensure their server is configured properly. TLS 1.2 is the most recent version of the SSL/TLS protocol, and most modern servers have it turned on by default. Forward secrecy refers to the way that connections are encrypted. An encryption cipher which supports forward secrecy, like ECDHE, is able to offer security to past sessions even if the private key is compromised.
So, server providers are moving towards this to improve the security of their customers data and communication.
Listen to the audio version of this post onĀ Hacker Public Radio!