How TLS1.3 Decryption Works?

How does a next gen firewall Palo Alto decrypts TLS 1.3 connections?

To my understanding in TLS 1.3, SNI sent in "Client Hello" is encrypted with the public key published by the owner of the website in a DNS TXT record.

Thus when connecting to such website, firewall like Palo Alto can not see where the client is trying to connect (since SNI is Encrypted) and consequently can not act as a forward proxy and open a connection on behalf of the user.

I found a Palo Alto Support article which describes how to configure TLS 1.3 decryption but it does not describes how decryption works under the hood

https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-admin/decryption/decryption-concepts/tlsv13-ssl-decryption-support

>Solution :

To my understanding in TLS 1.3, SNI sent in "Client Hello" is encrypted …

No. There are proposals like ESNI (encrypted SNI) and ECH (Encryped ClientHello) but these are not part of TLS 1.3. There are some public experiments with these though.

.. can not see where the client is trying to connect (since SNI is Encrypted) and consequently can not act as a forward proxy and open a connection on behalf of the user.

If a TLS intercepting firewall is deployed in transparent mode it can get the target IP address from the clients packet – but this might not be sufficient to create a TLS connection to a server which requires SNI. So clear SNI in the original ClientHello (as TLS 1.3 provides) is needed. Note though that a firewall might simply block traffic with ESNI or ECH in order to force the client to use clear SNI – see also China is now blocking all encrypted HTTPS traffic that uses TLS 1.3 and ESNI.

If the TLS intercepting firewall is deployed as an explicit firewall the requested domain is found in the CONNECT request to the proxy, so it does not need to be extracted from the ClientHello.

Leave a Reply