- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: Custom URL matching with HTTPS categorization
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Custom URL matching with HTTPS categorization
Hi,
we are still having issues with rules using custom URLs matching for HTTPS requests. It is working *sometimes*, but most often it is not working (rules doesn't match).
We are using HTTPS categorization only, as HTTPS inspection introduced other issues to us (nothing to discuss here).
From my understanding, while having HTTPS categorization in place, the firewall should match the URL against the CN of the SSL certificate of the site being accessed.
This indeed seems to work ok for cases where the CN is just a plain string. But for a wildcard certificate, it is apparently not working as expected. An actual example:
Site we would like the rule to match: https://www.docker.com/
SSL certificate CN of this site is "*.docker.com", also in the certificate there is a "Subject Alternative Name" attribute including "docker.io".
In the URL object on the firewall we used regex like ".*docker\.com.*" (which should match everything containing docker.com). But rule doesn't match.
Please clarify the expected behavior, because I couldn't find anything in documentation:
- How is a site's wildcard certificate CN (eg. "*.docker.com") matched against the string in the custom URL object? Is the star in the CN treated as wildcard or just as a character without special meaning?
- Is the SSL certificate's SAN (Subject Alternative Name) taken into account for matching at all?
- If the latter is not the case, are there plans to improve matching to take it into account?
Together with support we got the rule working once - by adding ".*docker\.io.*" to the URL regex, but I am in doubt that this fixed the root cause. After some time the rule stopped working again without any change done on the firewall.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In releases prior to R80.30, we only match the CN of the certificate, not the SNI.
In R80.30+, we can also do this via the verified SNI.
If you use R80.30, you must have HTTPS Inspection enabled for this to work (not required for R80.40)
In other releases, you might try using the Application Control Signature Tool: Signature Tool for custom Application Control and URL Filtering applications
[Edited this post 14 June 2020) to reflect current reality)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are having same kind of issues in our environment. Without HTTPs inspection it will not work as expected on 100%. Some websites are categorized properly, but some of them doesn’t match at all even with wildcards.Also using regex without HTTPS inspection is not recommended way to define custom app object
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is funny, because Check Point support was suggesting to USE regex.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In releases prior to R80.30, we only match the CN of the certificate, not the SNI.
In R80.30+, we can also do this via the verified SNI.
If you use R80.30, you must have HTTPS Inspection enabled for this to work (not required for R80.40)
In other releases, you might try using the Application Control Signature Tool: Signature Tool for custom Application Control and URL Filtering applications
[Edited this post 14 June 2020) to reflect current reality)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, I (or let's say my users) would really appreciate if the SNI matching would make the way into the GA release. Is there any reason against? I will ask my Check Point contact about this also.
Indeed, using the ACST tool it is possible to check also SNI. I will give it a try.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I assume that we will bring this support into the maintrain, but not sure of the timelines on that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Local Checkpoint had provided the SNI wrapper HOTFIX for blocking the HTTPS sites and we are doing "Categorize HTTPS websites" not HTTPS Inspection. It worked after the installation with Take 154 and even the file had been added for BOOT SURVIVAL. After a week related some other troubleshooting i had done a reboot and the SNI feature stopped working.
- Tags:
- sni
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear
domain:etax.sichuan.chinatax.gov.cn,it's a https site,i can not limit with URL filtering rule,this is why?
I have check box of "Categorize HTTPS websites".
What is the probable cause? thanks!
My checkpoint R80.30 ,SMS with HF 191,Firewall with HF196.
I have test it by different serveral sms+sg ,all of them have the same issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I enable SNI support follow sk145112:
[Expert@WUXI-EDGE-FW01:0]# fw ctl get int enable_domain_fronting_protection
enable_domain_fronting_protection = 1
I also capture when client access "etax.sichuan.chinatax.gov.cn",i can see the sni from capture,as follow:
but it still can not match the url filtering rule.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
