The Challenge With TLS1.3 Decryption

There is usually a need to do “category-based” decryption by transparent devices. These are usually firewall devices deployed in a forward proxy setup. For example, we may need to decrypt HTTPS requests to all servers except those with URL categories of health and finance. With TLS1.3, the only way to achieve this is by parsing the Server Name Indication (SNI) TLS extension, which indicates the server’s domain name.

The problem with this approach is that SNI is sent in plaintext, which makes it vulnerable to spoofing. Thus, the firewall’s decryption and content filtering policies can be essentially bypassed, since both these policies are URL category based.

In saying that, TLS1.3 has a protocol extension, which allows the SNI to be encrypted. However, this means that granular “category-based” decryption exemption cannot be done anymore by the firewall. Furthermore, content filtering can only be done after decrypting the TLS encrypted payload and reading the plaintext URL. This can be a challenge in countries that don’t allow the decryption of sites categorised as health or finance.

In my opinion, signing the SNI “instead of encrypting it” might help solve this issue. If the SNI indicates a server name that is categorised as health or finance, the TLS Client Hello can be allowed by the NGFW to flow to the origin content server, which signs the SNI and sends back the signature in the Server Hello to be checked for integrity at the client side.

If, however, the SNI indicates a server name with a traffic category to be decrypted, then the NGFW can sign the SNI with its own RSA or ECDSA private key and send the signature in the Server Hello to the client.

In both scenarios above, if the SNI has been tampered with, the client will pick up the mismatch and raise a TLS error.