URL Filtering - TLS 1.3 Website

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.
Palo Alto Networks Approved
Palo Alto Networks Approved
Community Expert Verified
Community Expert Verified

URL Filtering - TLS 1.3 Website

L0 Member

Hi,

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 determind by checking certificate:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClRZCA0

"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?

 

Happy to hear from you guys soon,
Regards Eve

 

1 accepted solution

Accepted Solutions

L7 Applicator

Hi @tpmeier

 

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 - als 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.

 

Regards,

Remo

View solution in original post

2 REPLIES 2

L7 Applicator

Hi @tpmeier

 

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 - als 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.

 

Regards,

Remo

L1 Bithead

Vsys_remo is correct. Here are the three relevant points from this kb with title "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.
  • 1 accepted solution
  • 6203 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!