It’s time for our weekly UKFast Guest Blog, and today we’re on the topic of TLS 1.3.
If you’ve never heard the term before, TLS stands for Transport Layer Security. It’s what makes communication across computer networks and the internet safe and secure, through encryption. TLS is the modern version of SSL, both of which are known as cryptographic protocols and help protect the transfer of data across the web.
In today’s blog, we hear from Azure Engineer Matt Bradley, from ClearCloud at UKFast, as he explains what’s so special about TLS 1.3 and how it’s going to keep your data safer on the internet.
The first TLS version, TLS 1.0, was released all the way back in 1999 and upgraded to TLS 1.2 in 2006.
Since 2006 was a whole 13 years ago now, TLS 1.2 has been around for an incredibly long time. So, an evolution has been called for. With the introduction of TLS 1.3, secure communication over the internet will be faster and safer than it was before.
Before we look at the advantages of TLS 1.3, we should understand how the handshake currently works with its predecessor, TLS 1.2:
As shown in this diagram, first, the client sends a ‘Client Hello’ to the server. This contains a list of all of the protocols and cipher suites that it supports.
The server receives the ‘Client Hello’, decides which cipher suite to use (TLS negotiation typically works on the highest compatible cipher and protocol between the two endpoints) and returns a ‘Server Hello’ to the client. The Server Hello contains the agreed cipher to be used, a key share, certificate, and signature.
The client responds with its own key share and both sides communicate that they’re finished. It is only at this point that the client sends a HTTP request and you can securely enter your personal information.
Ignoring the TCP handshake that is needed for any form of communication, the TLS handshakes takes two round trips – back and forth, twice.
Now we’ve covered how TLS 1.2 works, let’s look at how TLS 1.3 differs:
Those of you who are avid ‘spot the difference’ players will notice that the TLS 1.3 handshake is quite different from that of TLS 1.2. TLS 1.3 only has one round trip to perform the handshake. When the ‘Client Hello’ is sent, it tells the server that it supports up to TLS 1.3 and then does something cool (OK, I may have just misused the word ‘cool’). It anticipates the ciphers that the server will use and includes that in its Client Hello, along with a key share to match those ciphers.
If the server agrees with those ciphers, it accepts it and sends back the final encryption key to be used. TLS negotiation in one round trip!
Having one less round trip as part of this may not seem that much, but it halves the time needed to complete the action. Depending on the speed of your internet, this could make it hundreds of milliseconds quicker. And the internet is all about speed!
However, TLS 1.3 can do even better. If you return to a website, the client sends a previously obtained PSK (Pre-Shared Key) AND the HTTP request in the first communication with the server.
Some people may be worried that using a Pre-Shared Key (PSK) for this makes it less secure, but there are some caveats to 0-RTT with the conditions that it can be used. It will allow 0-RTT for GET requests, but as soon as you try and POST, PUT, PATCH, DELETE etc., it will send a new key share and renegotiate the connection. The PSK also only has a life cycle of around a week.
TLS 1.3 also makes the TLS session more secure as it disables obsolete ciphers and hashes that are no longer secure. So, you will no longer have to manually add DWORDS to the registry to disable these (which I hope everyone was doing previously). It will only support the strongest Diffie–Hellman key exchanges. Now that would give anyone a warm feeling inside!
If you’d like to read more on TLS 1.3 you can find a whitepaper on the topic here.
Check out our collection of guest blogs covering a range of tech and business topics.