Nominated Discussion: URL Filtering in TLS v1.3

[kiwi]

This Nominated Discussion Article is based on the post "URL Filtering - TLS 1.3 Website" by @tpmeier  and responded to by LIVEcommunity Cyber Elite expert @Remo and @RizwanJamil. Read on to see the discussion and solution!

I am new to Palo Alto Firewalls and am in the middle of testing some of the functionalities provided. One of which is URL Filtering.

I have been able to clone the default URL Filtering Profile. I then added a website to the blocked list. Then assigned the profile to a security policy. And it worked.

I found this knowledge base article confirming URL for HTTPS is determined by checking certificate:

URL filtering implementation and troubleshooting

"For HTTPS traffic, since this protocol is being encrypted, the firewall usually looks at data inside the Server Certificate that is presented to the client during the SSL handshake. In the case of decryption, this traffic will be treated as normal HTTP traffic when it comes to identifying the category."

Why are URLs for TLS 1.3 recognized ? With TLS 1.3  (as far as I understand) the certificate itself is not transferred in plain text anymore?

The firewall does not only check the certificate in TLS connections for URL filtering — it also (or primary) uses the SNI extension (server name indication) in a TLS handshake. This extension contains the FQDN in cleartext - also in TLS1.3 connections (even though starting with TLS1.3 it is possible to encrypt this value with additional config steps).

That's the reason why URL filtering still works for a lot of websites that use TLS1.3.

Here are the three relevant points from this kb "HOW TO IDENTIFY URL INFORMATION ON SSL TRAFFIC WITHOUT DECRYPTION":

• The SNI is used for URL categorization when SSL decryption is not enabled
• If the client does not send the SNI, then the  Common Name (CN) which represents the server name protected by the SSL certificate  is used for URL categorization
• Putting the hostname of the web server in the allow or block list of a URL filtering profile will essentially accomplish the same goal as using the CN to enforce policy

[Carleton]

With the adoption of TLS 1.3 support will this allow the identification for OID when checking remote OCSP responders for certificate validity? Currently we are unable to stop an error from occurring if we have User cetercerts in the same CA as the machine certificates. We have no way to identify OID and stop user cert checking after a machine cert has been verified. Product development told us this may be supported with the TLS 1.3 roll out as it does support OID checking.