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 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.
In summary, during the course of a TLS handshake, the client and server do the following:
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 the version of the TLS used. We will cover both versions herein.
Learn more about TLS and other machine identities. Read Machine Identity Protection for Dummies.
The TLS 1.2 Handshake Process
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:
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.
The TLS 1.3 handshake is shown in the picture below (courtesy of Cloudflare).
Image 2: TLS 1.3 Handshake Process
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 which 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
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
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:
This oversight resulted in a number of high-profile vulnerabilities. The FREAK, LogJam and CurveSwap attacks took advantage of two things:
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 downgrade 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 a HTTP GET message but a 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.