What is a TLS Handshake?
A TLS handshake is the process that kicks off a communication session that uses TLS encryption. During a TLS handshake, the two communicating sides exchange messages to acknowledge each other, verify each other, establish the encryption algorithms they will use, and agree on session keys. TLS handshakes are a foundational part of how HTTPS works and it is defined in RFC 8446 (for TLS 1.3) or in RFC 5246 (for TLS 1.2).
A TLS handshake takes place whenever a user navigates to a website over HTTPS and the browser first begins to query the website's origin server. TLS handshakes occur after a TCP connection has been opened via a TCP handshake.
What happens during a TLS handshake?
In summary, during the course of a TLS handshake, the client and server do the following:
- Agree on the version of the protocol to use
- Decide on which cipher suites—which set of cryptographic algorithms—they will use
- Authenticate each other by exchanging and validating digital certificates
- Use asymmetric encryption techniques to generate a shared secret key, called a session key, in order to use symmetric encryption after the handshake is complete
What are the steps of a TLS handshake?
TLS handshakes are a series of datagrams, or messages, exchanged by a client and a server. A TLS handshake involves multiple steps, as the client and server exchange the information necessary for completing the handshake and making further conversation possible.
The exact steps within a TLS handshake vary depending upon the kind of key exchange algorithm used (RSA or Diffie-Hellman) and the cipher suites supported by both sides. In addition, following the introduction of TLS 1.3, the TLS handshake varies depending on the version of the TLS used. We will cover both versions herein.
TLS Machine Identity Management for Dummies
The TLS 1.2 Handshake Process
- The “client hello” message: The client sends a “client hello” message that lists cryptographic information such as the TLS version and, the cipher suites supported by the client in an order of preference. The message also contains a string of random bytes, known as the “client random”, that is used in subsequent computations.
- The “server hello” message: The server responds with a “server hello” message that contains the cipher suite chosen by the server from the list provided by the client, the session ID, and another string of random bytes, called the “server random”. The server also sends its TLS certificate. If the server requires a digital certificate for client authentication, the server sends a "client certificate request" that includes a list of the types of certificates supported and the Distinguished Names of acceptable Certification Authorities (CAs).
- Server authentication: The client verifies the server's TLS certificate with the certificate authority that issued it. This confirms that the server is who it says it is, and that the client is interacting with the actual owner of the domain.
- Premaster secret: The client sends one more random string of bytes, the “premaster secret.” The premaster secret is encrypted with the server’s public key (included in the server’s TLS certificate) and can only be decrypted with the private key by the server.
- Client authentication: If the server has sent a “client certificate request”, the client sends its digital certificate. The server verifies the client's certificate.
- Session keys creation: The server decrypts the premaster secret. Both client and server generate session keys from the client random, the server random, and the premaster secret.
- Client is ready: The client sends the server a “finished” message, which is encrypted with the secret session key, indicating that the client part of the handshake is complete.
- Server is ready: The server sends the client a “finished” message, which is encrypted with the secret session key, indicating that the server part of the handshake is complete.
- Secure symmetric encryption achieved: For the duration of the TLS session, the server and client can now exchange messages that are symmetrically encrypted with the shared secret session key.
The TLS handshake process is also depicted in the picture below (courtesy of IBM).
Image 1: TLS 1.2 Handshake
TLS 1.3 Handshake Process
The introduction of TLS 1.3 has brought several improvements, with the most important being phasing out insecure algorithms and cipher suites. The IETF has also improved the TLS handshake process, which is as follows:
- Similar to the TLS 1.2 handshake, the TLS 1.3 handshake commences with the “Client Hello” message, but there is one significant change. The client sends the list of supported cipher suites and guesses which key agreement protocol the server is likely to select. The client also sends its key share for that particular key agreement protocol.
That saves a whole round trip, because as soon as the server selects the cipher suite and key agreement algorithm, it's ready to generate the key, as it already has the client key share. So it can switch to encrypted packets one whole round-trip in advance.
- In reply to the “Client Hello” message, the server replies with the key agreement protocol that it has chosen. The “Server Hello” message also comprises of the server’s key share, its certificate, which is now encrypted, as well as the “Server Finished” message.
- The client checks the server certificate, generates keys as it has the key share of the server, and sends the “Client Finished” message. From here on, the encryption of the data begins. This way, the TLS 1.3 handshake saves an entire round-trip and hundreds of milliseconds.
The TLS 1.3 handshake is shown in the picture below (courtesy of Cloudflare).
Image 2: TLS 1.3 Handshake Process
TLS Session Resumption
One existing way to speed up TLS connections is called resumption. It's what happens when the client has connected to that server before, and uses what they remember from the last time to cut short the handshake.
Resumption in TLS 1.2
In TLS 1.2 the server would send the client either a Session ID or a Session Ticket. The former is a reference number that the server can trace back to a session, while the latter is an encrypted serialized session that is stored in the client and not in the server.
The next time the client would connect, it would send the Session ID or Ticket in the ClientHello, and the server would acknowledge the identity of the client, jumping straight to the “finished” messages and saving a round-trip. The image below shows how session resumption works in TLS 1.2 (courtesy of Cloudflare).
Image 3: Session Resumption in TLS 1.2
Resumption in TLS 1.3 (0-RTT Resumption)
In TLS 1.2 there is a way to do 1-RTT connections if the client has connected before, which is very common. When resumption is available, TLS 1.3 allows us to do 0-RTT connections, again saving one round trip and ending up with no round trip at all. If you have already connected to a server supporting TLS 1.3, you can actually start sending encrypted data immediately, like an HTTP request, without any round-trip at all, making TLS essentially zero overhead.
When a TLS 1.3 client connects to a TLS 1.3 server, they agree on a resumption key (called pre-shared key or PSK), and the server gives the client a Session Ticket that will help it remember it. The Ticket can be an encrypted copy of the PSK—to avoid state—or a reference number.
The next time the client connects, it sends the Session Ticket in the ClientHello message and then immediately, without waiting for any round trip, sends the HTTP request encrypted with the PSK. The server figures out the PSK from the Session Ticket and uses that to decrypt the 0-RTT data.
The client also sends a key share, so that client and server can switch to a new fresh key for the actual HTTP response and the rest of the connection.
The image below shows how 0-RTT works (courtesy of Cloudflare).
Image 4: 0-RTT Resumption in TLS 1.3
TLS Handshake Vulnerabilities
One of the biggest fears with the handshake is the amount of data sent in plaintext. Obviously, that opens the door to problems, so the more of the handshake that can be secured, the better.
TLS 1.2 Vulnerabilities
Reviewing the negotiation stages in the TLS 1.2 handshake we can realize that these were not secured. Instead, a simple Message Authentication Code (MAC) is used to ensure nobody tampered with what was transmitted. That includes:
- The cipher suites supported by the client in the Client Hello message.
- In the Server Hello message the server-selected cipher suite, the key share, the TLS certificate and the digital signature.
This oversight resulted in a number of high-profile vulnerabilities. The FREAK, LogJam and CurveSwap attacks took advantage of two things:
- the fact that intentionally weak ciphers from the 1990s (called export ciphers) were still supported in many browsers and servers, and
- the fact that the part of the handshake used to negotiate which cipher was used was not digitally signed.
These attacks are called downgrade attacks, and they allow “man-in-the-middle” attackers to force two participants to use the weakest cipher supported by both parties, even if more secure ciphers are supported. In this style of attack, the perpetrator sits in the middle of the handshake and changes the list of supported ciphers advertised from the client to the server to only include weak export ciphers. The server then chooses one of the weak ciphers, and the attacker figures out the key with a brute-force attack, allowing the attacker to forge the MACs on the handshake.
Downgrade attacks open the door for other known exploits that affect whatever version that was downgraded to. That’s why they’re particularly dangerous.
In the case of session resumption, research has demonstrated that web sites could track browser users’ history by exploiting the session resumption feature implemented in the TLS protocol.
TLS 1.3 Vulnerabilities
In TLS 1.3 the above vulnerability that leads to downgrading attacks is prevented because the server signs the entire handshake, including the cipher negotiation.
On the other hand, the TLS 1.3 supported 0-RTT comes with a couple of caveats.
The first is that 0-RTT does not provide Forward Secrecy against a compromise of the Session Ticket key. It means that if these session ticket keys are compromised, an attacker can decrypt the 0-RTT data sent by the client but not the rest of the connection. Of course, this can easily be avoided by rotating session keys regularly. But considering TLS 1.2 doesn’t support full forward secrecy at all, TLS 1.3 is definitely an improvement.
More problematic are replay attacks. Since with Session Tickets servers are stateless, they have no way to know if a packet of 0-RTT data was already sent before.
If attackers can intercept a 0-RTT packet, then they could resend it multiple times—this is called a replay attack—without the server knowing the request is forged. If that 0-RTT data is not an HTTP GET message but an HTTP POST executing a transaction, then the attacker can escape with many thousands of dollars or euros.
The latest version of TLS won't matter if your certificates expire. Find out what happens in a TLS certificate outage, and what Venafi can do to help.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related posts