Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor

Custom URL matching with HTTPS categorization

Jump to solution

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.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Admin
Admin

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)

View solution in original post

9 Replies
Highlighted

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

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...


0 Kudos
Highlighted
Contributor

This is funny, because Check Point support was suggesting to USE regex.

0 Kudos
Highlighted
Admin
Admin

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)

View solution in original post

Highlighted
Contributor

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.

0 Kudos
Highlighted
Admin
Admin

I assume that we will bring this support into the maintrain, but not sure of the timelines on that. 

0 Kudos
Highlighted
Contributor

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 (1)
0 Kudos
Highlighted
Advisor

Dear 

      domain:etax.sichuan.chinatax.gov.cn,it's a https site,i can not limit with URL filtering rule,this is why?

 

Spoiler
I set the rule as follow:

 

1.png

 
Spoiler
This domain "Commom names" and "Alternative" is :*.sichuan.chinatax.gov.cn 

2.png

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.

 

0 Kudos
Highlighted
Advisor

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:

SNI.png

but it still can not match the url filtering rule.

0 Kudos
Highlighted
Advisor
this is certificate issue. the ca cert of this site not be trust,so firewall drop the traffic,i tried to import the ca to trusts ca in https inspection and install policy,then reboot the firewall,all work.