The TLS 1.3 handshake is a dramatic improvement over the TLS 1.2 handshake
The wait for TLS 1.3 seems like it may never end. Right now, the IETF (Internet Engineering Task Force) is on the 27th draft. Fortunately, many say that the drafting process is nearing its end. And while there have been some speed-bumps along the way hopefully, TLS 1.3 is finally about to be released.
The reason why TLS 1.3 is so highly anticipated is improvements it brings us over TLS 1.2, the best and the longest-serving member of the SSL/TLS family.
Primarily, TLS 1.3 brings two advancements compared to TLS 1.2, and they are made in the interest of security and speed. TLS 1.3 cuts out the outdated and confusing encryption options supported by TLS 1.2 that are potentially insecure. This doesn’t mean that TLS 1.2 is insecure—TLS 1.2 still is secure. While none of these potential insecurities have been exploited in the wild, the key word is potential.
When it comes to TLS 1.3 though, its handshake process is what has people buzzing. In this article, you’ll understand why.
But before we can get to that, let’s go over what the handshake looks like in TLS 1.2. After all, you’re not going to understand the improvements in the TLS 1.3 handshake without knowing about the TLS 1.2 handshake first.
So, let’s have a closer look at the TLS 1.2 handshake.
TLS 1.2 Handshake
The TLS 1.2 handshake, which is similar to that of TLS 1.0 and 1.1, involves a series of back-and-forth communications between client and server.
To simplify things a little more I’ve lumped a few of these steps together.
Step 1: The entire connection/handshake begins with the client sending a “client hello” message to the server. This message consists of cryptographic information such as supported protocols and supported CipherSuites. It’s also comprised of a random value or random byte string.
Step 2: In response to the client’s “client hello” message, server responds with “server hello” message. This message includes the CipherSuite that the server has chosen out of the ones offered by the client. The server also sends its certificate along with the session ID and another random value.
Step 3: Now the client verifies the certificate sent by the server. Once the verification is done, it sends a random byte string, also called “pre-master secret,” and encrypts it using the public key of server’s certificate.
Step 4: Once the server receives the pre-master secret, the client, and server both generate a master key along with session keys (ephemeral keys). These session keys will be used to symmetrically encrypt the data.
Step 5: Now the client sends a “Change Cipher Spec” message to the server to let it know that it’s going to switch to symmetric encryption with the help of session keys. Along with it, it also sends “Client Finished” message.
Step 6: In reply to the client’s “Change Cipher Spec” message, the server does the same and switches its security state to symmetric encryption. The server concludes the handshake by sending “server finished” message.
As you can see, it took two round-trips between the client and the server to complete the handshake. On average, this takes somewhere between 0.25 seconds to 0.5 seconds. However, it could take more depending on several factors. At first, half a second may not seem like a lot of time but remember; this is just the handshake, the data transfer hasn’t even started yet. When you compare the TTFB (time to the first byte) of HTTP and HTTPS sites, the TTFB of HTTPS site takes longer when compared to that of an HTTP site, especially when the site is running on HTTP/1.
TLS 1.3 Handshake
The TLS 1.3 handshake process involves only one round-trip as opposed to three in TLS 1.2. This results in reduced latency.
Step 1: Similar to the TLS 1.2 handshake, the TLS 1.3 handshake commences with the “Client Hello” message – with one significant change. The client sends the list of supported cypher 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.
Step 2: 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 as well as the “Server Finished” message.
The “Server Finished” message, which was sent in the 6th step in TLS 1.2 handshake, is sent in the second step. Thereby, saving four steps and one round trip along the way.
Step 3: Now, 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. A major improvement over the TLS 1.2 handshake. You might be inclined to say that this makes no or very little difference, but no! In 2006, back when people had a thing called patience, Marissa Mayer revealed that a delay of half a second resulted in 20% traffic decline. Twenty Percent!!!
0-RTT Resumption: The Good
Another major milestone that TLS 1.3 is set to accomplish is 0-RTT Resumption. It means that if the client has connected to the server before, TLS 1.3 permits a zero-round trip handshake. This is accomplished by storing secret information (typically, Session ID or Session Tickets) of previous sessions and using them when both parties connect with each other in future.
0-RTT Resumption: The Bad
However, there are few concerns when it comes to the security in 0-RTT resumption sessions. The first being the lack of full forward secrecy. It means that if these session ticket keys are compromised, an attacker can decrypt the 0-RTT data sent by the client on the first flight. 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.
The second security concern when it comes to TLS 1.3 0-RTT is that it doesn’t provide a guarantee of non-replay between connections. If an attacker somehow manages to get hold of your 0-RTT encrypted data, it can fool the server into believing that the request came from the server since it has no way of knowing where the data came from. If an attacker sends this request multiple times, it’s called ‘replay attack.’ It’s not as easy as it sounds and obviously, there are certain mechanisms to prevent that (more on that in another post).
Final Thoughts
Needless to say, TLS 1.3 offers significant improvements regarding security as well as latency. You can experience the power of TLS 1.3 as Chrome and Firefox have enabled support for its drafts. The only thing that remains to be seen is when it gets published and becomes a standard. The thing for sure is that it will serve us for years to come!
The TLS 1.3 handshake is a dramatic improvement over the TLS 1.2 handshake
The wait for TLS 1.3 seems like it may never end. Right now, the IETF (Internet Engineering Task Force) is on the 27th draft. Fortunately, many say that the drafting process is nearing its end. And while there have been some speed-bumps along the way hopefully, TLS 1.3 is finally about to be released.
The reason why TLS 1.3 is so highly anticipated is improvements it brings us over TLS 1.2, the best and the longest-serving member of the SSL/TLS family.
Primarily, TLS 1.3 brings two advancements compared to TLS 1.2, and they are made in the interest of security and speed. TLS 1.3 cuts out the outdated and confusing encryption options supported by TLS 1.2 that are potentially insecure. This doesn’t mean that TLS 1.2 is insecure—TLS 1.2 still is secure. While none of these potential insecurities have been exploited in the wild, the key word is potential.
When it comes to TLS 1.3 though, its handshake process is what has people buzzing. In this article, you’ll understand why.
But before we can get to that, let’s go over what the handshake looks like in TLS 1.2. After all, you’re not going to understand the improvements in the TLS 1.3 handshake without knowing about the TLS 1.2 handshake first.
So, let’s have a closer look at the TLS 1.2 handshake.
TLS 1.2 Handshake
The TLS 1.2 handshake, which is similar to that of TLS 1.0 and 1.1, involves a series of back-and-forth communications between client and server.
To simplify things a little more I’ve lumped a few of these steps together.
Step 1: The entire connection/handshake begins with the client sending a “client hello” message to the server. This message consists of cryptographic information such as supported protocols and supported CipherSuites. It’s also comprised of a random value or random byte string.
Step 2: In response to the client’s “client hello” message, server responds with “server hello” message. This message includes the CipherSuite that the server has chosen out of the ones offered by the client. The server also sends its certificate along with the session ID and another random value.
Step 3: Now the client verifies the certificate sent by the server. Once the verification is done, it sends a random byte string, also called “pre-master secret,” and encrypts it using the public key of server’s certificate.
Step 4: Once the server receives the pre-master secret, the client, and server both generate a master key along with session keys (ephemeral keys). These session keys will be used to symmetrically encrypt the data.
Step 5: Now the client sends a “Change Cipher Spec” message to the server to let it know that it’s going to switch to symmetric encryption with the help of session keys. Along with it, it also sends “Client Finished” message.
Step 6: In reply to the client’s “Change Cipher Spec” message, the server does the same and switches its security state to symmetric encryption. The server concludes the handshake by sending “server finished” message.
As you can see, it took two round-trips between the client and the server to complete the handshake. On average, this takes somewhere between 0.25 seconds to 0.5 seconds. However, it could take more depending on several factors. At first, half a second may not seem like a lot of time but remember; this is just the handshake, the data transfer hasn’t even started yet. When you compare the TTFB (time to the first byte) of HTTP and HTTPS sites, the TTFB of HTTPS site takes longer when compared to that of an HTTP site, especially when the site is running on HTTP/1.
TLS 1.3 Handshake
The TLS 1.3 handshake process involves only one round-trip as opposed to three in TLS 1.2. This results in reduced latency.
Step 1: Similar to the TLS 1.2 handshake, the TLS 1.3 handshake commences with the “Client Hello” message – with one significant change. The client sends the list of supported cypher 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.
Step 2: 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 as well as the “Server Finished” message.
The “Server Finished” message, which was sent in the 6th step in TLS 1.2 handshake, is sent in the second step. Thereby, saving four steps and one round trip along the way.
Step 3: Now, 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. A major improvement over the TLS 1.2 handshake. You might be inclined to say that this makes no or very little difference, but no! In 2006, back when people had a thing called patience, Marissa Mayer revealed that a delay of half a second resulted in 20% traffic decline. Twenty Percent!!!
0-RTT Resumption: The Good
Another major milestone that TLS 1.3 is set to accomplish is 0-RTT Resumption. It means that if the client has connected to the server before, TLS 1.3 permits a zero-round trip handshake. This is accomplished by storing secret information (typically, Session ID or Session Tickets) of previous sessions and using them when both parties connect with each other in future.
0-RTT Resumption: The Bad
However, there are few concerns when it comes to the security in 0-RTT resumption sessions. The first being the lack of full forward secrecy. It means that if these session ticket keys are compromised, an attacker can decrypt the 0-RTT data sent by the client on the first flight. 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.
The second security concern when it comes to TLS 1.3 0-RTT is that it doesn’t provide a guarantee of non-replay between connections. If an attacker somehow manages to get hold of your 0-RTT encrypted data, it can fool the server into believing that the request came from the server since it has no way of knowing where the data came from. If an attacker sends this request multiple times, it’s called ‘replay attack.’ It’s not as easy as it sounds and obviously, there are certain mechanisms to prevent that (more on that in another post).
Final Thoughts
Needless to say, TLS 1.3 offers significant improvements regarding security as well as latency. You can experience the power of TLS 1.3 as Chrome and Firefox have enabled support for its drafts. The only thing that remains to be seen is when it gets published and becomes a standard. The thing for sure is that it will serve us for years to come!
Recent Posts
Recent Comments
Archives
Categories
Meta
About Me
Zulia Maron Duo
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore.
Popular Categories
Instagram Feeds
Error: No connected account.
Please go to the Instagram Feed settings page to connect an account.
Archives