{"id":6086,"date":"2018-03-20T14:02:47","date_gmt":"2018-03-20T18:02:47","guid":{"rendered":"https:\/\/www.thesslstore.com\/blog\/?p=6086"},"modified":"2023-03-20T14:29:58","modified_gmt":"2023-03-20T18:29:58","slug":"tls-1-3-handshake-tls-1-2","status":"publish","type":"post","link":"https:\/\/www.thesslstore.com\/blog\/tls-1-3-handshake-tls-1-2\/","title":{"rendered":"TLS 1.3 Handshake: Taking a Closer Look"},"content":{"rendered":"

The TLS 1.3 handshake is a dramatic improvement over the TLS 1.2 handshake<\/h2>\n

The wait for TLS 1.3 seems like it may never end. Right now, the IETF (Internet Engineering Task Force) is on the 27th<\/sup> 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.<\/p>\n

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.<\/span><\/p>\n

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\u2014TLS 1.2 still is secure. While none of these potential insecurities have been exploited in the wild, the key word is potential.<\/p>\n

When it comes to TLS 1.3 though, its handshake process is what has people buzzing. In this article, you’ll understand why.<\/p>\n

But before we can get to that, let\u2019s go over what the handshake looks like in TLS 1.2. After all, you\u2019re not going to understand the improvements in the TLS 1.3 handshake without knowing about the TLS 1.2 handshake first.<\/p>\n

So, let\u2019s have a closer look at the TLS 1.2 handshake.<\/p>\n<\/span><\/span>\n

TLS 1.2 Handshake<\/h2>\n

The TLS 1.2 handshake<\/a>, which is similar to that of TLS 1.0 and 1.1, involves a series of back-and-forth communications between client and server.\u00a0<\/strong><\/p>\n

\"TLS<\/p>\n

To simplify things a little more I\u2019ve lumped a few of these steps together.<\/p>\n

Step 1:<\/strong> The entire connection\/handshake begins with the client sending a \u201cclient hello\u201d message to the server. This message consists of cryptographic information such as supported protocols and supported CipherSuites. It\u2019s also comprised of a random value or random byte string.<\/p>\n

Step 2:<\/strong> In response to the client\u2019s \u201cclient hello\u201d message, server responds with \u201cserver hello\u201d 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.<\/p>\n

Step 3:<\/strong> 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.<\/p>\n

Step 4:<\/strong> 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.<\/p>\n

Step 5:<\/strong> Now the client sends a \u201cChange Cipher Spec\u201d message to the server to let it know that it\u2019s going to switch to symmetric encryption with the help of session keys. Along with it, it also sends \u201cClient Finished\u201d message.<\/p>\n

Step 6: <\/strong>In reply to the client\u2019s \u201cChange Cipher Spec\u201d message, the server does the same and switches its security state to symmetric encryption. The server concludes the handshake by sending \u201cserver finished\u201d message.<\/p>\n

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.<\/p>\n

TLS 1.3 Handshake<\/h2>\n

The TLS 1.3 handshake process involves only one round-trip as opposed to three in TLS 1.2. This results in reduced latency.<\/span><\/p>\n

\"TLS<\/p>\n

Step 1: <\/strong>Similar to the TLS 1.2 handshake, the TLS 1.3 handshake commences with the \u201cClient Hello\u201d message \u2013 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.<\/p>\n

Step 2: <\/strong>In reply to the \u201cClient Hello\u201d message, the server replies with the key agreement protocol that it has chosen. The \u201cServer Hello\u201d message also comprises of the server\u2019s key share, its certificate as well as the \u201cServer Finished\u201d message.<\/p>\n

The \u201cServer Finished\u201d message, which was sent in the 6th<\/sup> step in TLS 1.2 handshake, is sent in the second step. Thereby, saving four steps and one round trip along the way.<\/p>\n

Step 3: <\/strong>Now, the client checks the server certificate, generates keys as it has the key share of the server, and sends the \u201cClient Finished\u201d message. From here on, the encryption of the data begins.<\/p>\n

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!!!<\/p>\n

0-RTT Resumption: The Good<\/h2>\n

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.<\/p>\n

0-RTT Resumption: The Bad<\/h2>\n

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\u2019t support full forward secrecy at all, TLS 1.3 is definitely an improvement.<\/p>\n

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\u2019s called \u2018replay attack.\u2019 It\u2019s not as easy as it sounds and obviously, there are certain mechanisms to prevent that (more on that in another post).<\/p>\n<\/span><\/span>\n

Final Thoughts<\/h2>\n

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!<\/p>\n","protected":false},"excerpt":{"rendered":"

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…<\/p>\n","protected":false},"author":10,"featured_media":6090,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":"","tve_updated_post":"","tve_custom_css":"","tve_user_custom_css":"","tve_globals":{},"tcb2_ready":0,"tcb_editor_enabled":0,"tve_landing_page":"","_tve_header":"","_tve_footer":""},"categories":[130],"tags":[214],"class_list":["post-6086","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-everything-encryption","tag-tls-1-3","post-with-tags"],"views":99325,"jetpack_featured_media_url":"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/03\/iStock-635731008.jpg","_links":{"self":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/6086","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/comments?post=6086"}],"version-history":[{"count":0,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/6086\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media\/6090"}],"wp:attachment":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media?parent=6086"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/categories?post=6086"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/tags?post=6086"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}