URL filtering without HTTPs inspection

[Kevin_Vargo]

Hi - I recently added URL Filtering and App control to a new cluster for guest traffic.  I found that access to thepiratebay.org is allowed even though the site is categorized as illegal/questionable (which I have set to block).  According to curl this seems due to the fact that the http request ultimately redirects to the https  site and the CN being used is for cloudflaressl.com, which is categorized as internet/computers.  Therefore the traffic makes it through and the page loads.  Outside of enabling HTTPs inspection or creating a specific block rule to that IP address, can others offer ideas on how I may be able to block this access? I am looking for something broad as I am sure other sites I've not run across do the same redirect.  Also I am relatively new to this work so forgive me if this was answered elsewhere or is common knowledge.  Thank you.

[PhoneBoy]

The actual website being accessed is communicated in SNI (Server Name Extension).

Because SNI is trivial to spoof, we do not use it for security decisions.

This is documented in: Application Control cannot detect web application if traffic is over SSL and HTTPS Inspection is dis... 

A potential workaround for this is to create a specific signature for the site using the signature tool: Signature Tool for custom Application Control and URL Filtering applications 

[Johnathan_Brow1]

In this case thepiratebay.com had to return a certificate that is valid for this domain, which the gateway should be able to inspect.

I checked a site I knew used CloudFlare and when checking the certificate the CN=sni136990.cloudflaressl.com, but the real domain name was in the subjectAltName property that Check Point do not inspect. Why I don't know

I recently did some tests to test the URLF/AppCtrl without using HTTPS inspection, and only relying on HTTPS categorization. Here are the limitations I found.

Allowing a custom site: www.amazon.com

Visit URL: https://www.amazon.com

Certificate CN=www.amazon.com

Status: works

Allowing a custom site: www.google.se

Visit URL: https://www.google.se

Certificate CN=*.google.se

Status: does not work. Check point translates a CN=*.google.se -> https://google.se

This means that I need to allow a custom site with name "google.se" to get this to work

From a debug we can see this behaviour

;27Feb2018 12:47:55.399003;[cpu_2];[fw4_2];1519735675:{policy,urlf_ssl} appi_rad_uf_cmi_handler_match_cb: call appi_user_cmi_handler_handle_url() with cn='google.se' (10);

;27Feb2018 12:47:55.399005;[cpu_2];[fw4_2];1519735675:{urlf_ssl} appi_user_cmi_handler_handle_url: url_https_normalized = 'https://google.se' (18);

Allowing a custom site: www.youtube.com

Visit URL: https://www.youtube.com

Certificate CN=*.google.com (SubjectAltName=www.youtube.com and youtube.com)

Status: does not work. Check Point does not seem to read SubjectAltName from the certificate.

Right now there seem to be some limitations on what Check Point can do without SSL inspection. Anyone know any plans for them to support wildcard and multidomain certificates? I cannot see any technical reason not to like with SNI.

[MikeB]

Hi @Johnathan_Brow1, we are experiencing these problems increasingly with our customers right now in R80.10.

Are you were able to find a workaround to this problem?

I hope that with R80.30 it can be solved or improved with this:

[Johnathan_Brow1]

On another note, the article you pointed to seem to suggest Check Point does use SNI if it is available.

"In some cases, YouTube can be detected by the SNI (Server Name Indication = extension to the TLS computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process) as part of the client hello. However, it is not guaranteed this extension will be always used."

[Marco_Valenti]

You can try to work with  regex for specific url as specified in r77.30 app control e url filtering administrative guide you should be able to block this kind of traffic with that or atl least it's worth a try

[Neil_ZInk]

Expanding on Marco's reply

Enable "Categorize HTTPS websites"  under global settings -> application Control & URL Filtering

Create a New Override Categorization (or group)

Make sure you have the Category blocked in Application policy

when we were on  77.30  we needed a special wrapper created that addresses some of inconsistencies of application/url blade with HTTPS sites.     the wrapper is available for Take 101 (fw1_wrapper_HOTFIX_R7730_T101_JHF_864.tgz) and 205 (fw1_wrapper_HOTFIX_R7730_JHF_T205_658_GA_FULL.tgz).   The wrapper has been incorporated into r80.10.

[Markus_Marquard · Accepted solution]

Hi, thanks for your tests - I am running into similar problems currently (R80.10).

Checkpoint should really implement subjectAltName property being checked against the URL filter. More and more sites are using this.

[Gaurav_Pandya]

Hi,

I had a issue with proper categorization without https inspection. I have enabled below setting (Categorize https sites)and after that URL Categorization and action (Block/permit) is performed as expected.