10/25/22, 6:16 PM TLS 1.

3 – Decryption Misconceptions :: The Ramblings of a Security Guy

> $ cd /home/

About

Posts
7 minutes

TLS 1.3 – Decryption

Misconceptions
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

https://mikeguy.co.uk/posts/2018/11/tls-1.3-decryption-misconceptions/ 1/8
10/25/22, 6:16 PM TLS 1.3 – Decryption Misconceptions :: The Ramblings of a Security Guy

you own it (along with your public key), without actually

> $ cd /home/
providing the key
Your public key is widely distributed to all and sundry. It can be
About
used to verify the signature above. Anything encrypted with a
public key can also only be decrypted with the corresponding Posts
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!

https://mikeguy.co.uk/posts/2018/11/tls-1.3-decryption-misconceptions/ 2/8
10/25/22, 6:16 PM TLS 1.3 – Decryption Misconceptions :: The Ramblings of a Security Guy

> $ cd /home/

About

Posts

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!

https://mikeguy.co.uk/posts/2018/11/tls-1.3-decryption-misconceptions/ 3/8
10/25/22, 6:16 PM TLS 1.3 – Decryption Misconceptions :: The Ramblings of a Security Guy

2) Ephemeral Diffie-Hellman key exchange

> $ cd /home/
Given the above, wouldn’t it be great if we could derive a
symmetric key securely over the Internet, without relying on the About
servers private key. What’s that?! We can! Enter more clever Posts
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.

https://mikeguy.co.uk/posts/2018/11/tls-1.3-decryption-misconceptions/ 4/8
10/25/22, 6:16 PM TLS 1.3 – Decryption Misconceptions :: The Ramblings of a Security Guy

> $ cd /home/

About

Posts

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,
https://commons.wikimedia.org/w/index.php?curid=1706304

https://mikeguy.co.uk/posts/2018/11/tls-1.3-decryption-misconceptions/ 5/8
10/25/22, 6:16 PM TLS 1.3 – Decryption Misconceptions :: The Ramblings of a Security Guy

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

So whats changed in TLS 1.3? Posts

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
https://mikeguy.co.uk/posts/2018/11/tls-1.3-decryption-misconceptions/ 6/8
10/25/22, 6:16 PM TLS 1.3 – Decryption Misconceptions :: The Ramblings of a Security Guy

the moment, but potentially something that could end up coming

> $ cd /home/
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).
About
Inline “Man in the middle” decryption (as implemented on many
Posts
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.

https://mikeguy.co.uk/posts/2018/11/tls-1.3-decryption-misconceptions/ 7/8
10/25/22, 6:16 PM TLS 1.3 – Decryption Misconceptions :: The Ramblings of a Security Guy

Summary
> $ cd /home/
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 About

how they will address the challenges – but time will tell! Posts

1486 Words
2018-11-30 00:00 +0000

← CIS Security Con… CIS Security Con… →

© 2020
Mike Guy
CC BY-NC 4.0

Powered by Hugo
Hugo template created by rhazdon
All opinions on this site are my own and do not reflect those of my employer,
family or friends unless otherwise quoted

https://mikeguy.co.uk/posts/2018/11/tls-1.3-decryption-misconceptions/ 8/8