TLS 1.3 was ratified as a standard earlier this year. It will be sometime before we are likely see it in heavy use, but there seem to be a number of misconceptions around it at the moment. I recently heard someone say that TLS 1.3 meant you could no longer “Man in the middle” traffic for decryption. There are elements of truth to this, but the message has gotten mixed up. This post aims to clear up some of the confusion around the new standard.

Why would you want to decrypt TLS in the first place? There are valid reasons for this and they have been briefly looked at in one of my previous posts which you can find here. We won’t be going over that again here.

A brief history lesson

To better understand some of the changes that TLS 1.3 brings, it is time for a quick refresher on TLS 1.2 and earlier. I don’t have a mathematics degree, so don’t expect this to be in depth! I’ve deliberately dumbed down details and left pieces out to keep things simple.

TLS and its predecessor – SSL – heavily rely on public/private key-pair technology. We won’t get into this too much, so just remember the following:

  • Keys are generated in pairs – there is always a public and private key and they are mathematically linked to each other
  • Your private key is just that – it is meant to be kept private. If you “sign” something with it, you validate to someone else that you own it (along with your public key), without actually providing the key
  • Your public key is widely distributed to all and sundry. It can be used to verify the signature above. Anything encrypted with a public key can also only be decrypted with the corresponding private key
  • X509 certificates bind a bunch of information together with a sites public key. The server signs it so you can be sure it came from the right place

Got it? Good. Public key cryptography is computationally expensive – so for bulk encryption of web pages it is no good. Instead, your browser and a web-server need to agree on a symmetric key for encryption – think of this as just a password they both know. In TLS 1.2 and earlier there were generally two ways to derive this symmetric key (remember – I’m deliberately keeping it simple!).

1) RSA-based key-exchange

The client browser would generate a random key, encrypt it with the web-servers public-key, send it to the server and the server would decrypt it with its private key. Happy days – they now both have the same symmetric key to use!

RSA Key Exchange

This approach is great for passive decryption by devices such as an IPS or other security devices that are not inline. Just provide the device a copy of your private key and it will have enough information to recover the session key and decrypt the data. Of course, the negative to this is should an attacker get hold of your private key they can decrypt any data they may have collected in the past. So an attacker could passively capture all this encrypted data for years – if they then manage to get a copy of the private key they can decrypt it all – not great!

2) Ephemeral Diffie-Hellman key exchange

Given the above, wouldn’t it be great if we could derive a symmetric key securely over the Internet, without relying on the servers private key. What’s that?! We can! Enter more clever mathematics – this time in the form of something known as Diffie Hellman.

I still haven’t obtained a degree in Mathematics since the last paragraph so again, this will be very dumbed down just to illustrate the theory. Diffie Hellman basically relies on each side generating two values – one they share with each other, one they keep to themselves. By combining the shared value, with the one they kept private, they are both able to arrive at the same answer (mental I know!). Anyone just observing in the middle though would not be able to generate the same key using just the publicly shared values.

The easiest to comprehend explanation of the theory I’ve seen relies on the use of colours to illustrate the process.

ECDHE Key Exchange By Original schema: A.J. Han Vinck, University of Duisburg-EssenSVG version: Flugaal – A.J. Han Vinck, Introduction to public key cryptography, p. 16, Public Domain,

What this all means, is that even with a copy of the private key an attacker couldn’t go and decrypt data that he had previously captured. Much more secure.

So whats changed in TLS 1.3?

Lots. But the most notable things for that which we are discussing here are:

  • No more RSA key exchange – Only the more secure Ephemeral Diffie Hellman based key exchanges are permitted
  • Certificates are encrypted – Usually the server-side certificate is sent in the clear and can be read by anyone viewing the traffic, but it is now encrypted
  • Optional SNI encryption – Server Name Indication (SNI) is a way for a browser to indicate to a server which website it is trying to access. Useful if you are hosting multiple different websites on the same IP address. In TLS 1.2 this was sent in the clear, but there is an optional extension in TLS 1.3 to allow the client to encrypt this

As you can probably tell, a lot of the changes in TLS 1.3 are around removing old, obsolete settings and improving privacy. By encrypting the certificate and optionally the SNI, it provides end users with more privacy from potential nosey organisations/individuals in the middle!

What does this all mean for enterprise decryption?

The changes in TLS 1.3 are great for end-user privacy, but do bring with it challenges for valid corporate decryption purposes. This tends to be where messaging and understanding of what is and isn’t possible gets mixed up.

Firstly, passive out-of-band decryption is out. The fact all key-exchanges will use Diffie Hellman means that devices such as IPS etc. cannot passively decrypt traffic even with a copy of the private key. They only way they would be able to decrypt data would be for one end of the conversation to provide a copy of the actual session key somehow. Not something that really exists at the moment, but potentially something that could end up coming out the back of this in the end (e.g. some sort of agent on your endpoints sends it securely to the appliance in question).

Inline “Man in the middle” decryption (as implemented on many firewalls and proxies) however will still be entirely possible. As long as your internal clients trust the device’s CA certificate then it will still be able to spoof the certificates and sit in the middle just as it does for TLS 1.2 today. The challenge TLS 1.3 poses however is the ability to whitelist/blacklist certain sites. A typical use-case for this whitelisting approach is to implement policies such as “bypass decryption for banking and healthcare”. This is possible with TLS 1.2 as the proxying device can see the cleartext certificate details, make a decision on the site category and drop out of the connection without breaking the session or decrypting anything.

With TLS 1.3 however, the certificate is encrypted. So the proxy in the middle has to establish a full TLS session before it can see the certificate details and determine a site category. At this point it can no longer gracefully drop out of the session and hand it back to the client – its too late. This means in practice that you are either going to have to proxy and decrypt everything (not great for performance, privacy or legality) or find an alternative method for deriving the site category without establishing the full session. The latter is something the industry is still working on, but two possible options would be tying this in with DNS requests to see what was requested for that IP or making extra calls to websites and caching category details ready for subsequent connections (again, additional load on the proxies and the actual end servers).

The observant of you may be thinking “well what about SNI – can’t we use that?”. Well yes, in theory. But keep in mind this is easily spoofable. If you relied on SNI for determining category, then malware could just be coded to provide an SNI that mapped to safe categories which may bypass decryption altogether. You’ll also recall that TLS 1.3 provides an optional extension for SNI encryption. So, even if SNI was safe to use for category determination, a proxy may not be able to view it anyway.


Hopefully this clarifies the situation around TLS 1.3 decryption a bit. It isn’t entirely clear where the industry will go with it yet and how they will address the challenges – but time will tell!