One of the more controversial and disruptive developments in the world of IT security is that of TLS 1.3., there are differing opinions on the impact of TLS 1.3, and whether the new changes are a help, or hindrance to operational cyber security. Previously in TLS 1.0, 1.1 and 1.2 the changes have been small steps forward, as opposed to the leap of 1.3. Due to the impact of this new change, we here at Softcat wanted to give a balanced overview of things.

What is TLS?

TLS, or transport layer security, is a cryptographic protocol, which is the successor from SSL (secure socket layer) and used to obfuscate network connections between a client and a server. For those particularly interested in how this works, I've broken it down as a conversation, please see below:

The client initiates a message called ClientHello, and offers some cipher suites (posh name for encryption process) to talk over. The server then replies with its hello, chooses a cipher suite, and shares an encryption key. The server will then send the website certificate which it will sign, so that the client ensures it’s authentic. Once that’s complete the client will then send over its portion of the key, along with a finish message. Lastly the server replies with a finish message and the communication can start.

What is TLS 1.3 then?

As you’d expect, TLS 1.3 bears similarity to that of its predecessor, but does have more notable changes than we’ve seen before. Following the same logic as the conversation previously, I’ve detailed the differences below.

As you can see, the main difference between the two versions is that within 1.3, there is a lot more packed into the first communication from both the client and server. The client is now sending over its portion of the encryption key within the ClientHello message, and the server when responding is also sending over its chosen encryption method, and its reciprocal encryption key. Crucially, as it has both the client’s key and its own generated one, the certificate that it then signs and sends is now already encrypted as it has already got both keys.

The real clever bit about this is that this is one less communication, because the client key has already been communicated. This means switch to encrypted packets is one step quicker, and in the world of the internet, quicker is always better.

So That’s Great, Right?

Well, in short, yes. TLS is going to decrease latency and allow for much more efficient communication, which is a good thing. That being said, not everyone is super keen on migrating to 1.3. One of the bigger issues that have been raised with TLS 1.3 is the challenges it brings to web filtering. Essentially, TLS 1.3 requires any web proxy to remain in-line (actively proxying) from the start of the transaction as the initial ServerHello message is encrypted and signed. Previously in TLS 1.1 & 1.2 this initial transaction was in the clear and enabled the proxy to intercept or not based upon this information.

So, What?

Well remaining in-line has two main implications:

• Performance
• Privacy

From a performance perspective, where proxies are used to broker only part of a connection, having to now broker full connections will increase the load, but for the same number of connections. This may mean that some proxy hardware will start to experience performance or scalability issues, especially if these are close to their connection capacity. Given the growth of both average WAN utilisation (221% YoY growth EMEA) and the encrypted web traffic (90% YoY growth and 75% encrypted 2019). Customers should be cautious about sizing any future requirements for network devices that perform HTTPS inspection.

From a privacy perspective, certain connections, (like that of internet banking) cannot be proxied fully else otherwise the confidential banking details of that user could be at risk. This means they will lose the ability to filter inspect at a granular (URL or method) level. This will only leave organisations with the ability to allow-list whole domains. This becomes even more complex when you consider multiple sites hosted on the same IP addresses.

We're going to see a lot more discussion around TLS 1.3, as the depreciation date for TLS 1.0 & 1.1 is at the end of June, so the longevity of TLS 1.2 is very much up for discussion.

Get in touch

If reading this has piqued your interest, or if you'd like to discuss how TLS 1.3 fits in as part of your security strategy, please get in contact, either through your account manager, or using the button below.