URL Filtering Categorization issues r80.30 without https inspection

[Khalid_Aftas]

Hi,

In the past we never succeded to make URL filtering/Appcontrol work as advertised in 77.30 & 80.10, now that we upgraded our vsx to r80.30 we decided to give it a shot.

In our policy we tested everything we could, simple rules with categories, rules with custom application & list of urls, and we are still having matching issues (blocked categories allowed, allowed categories blocked etc)

In R80.30, URL filtering should be using SNI to check the urls, as CN is not reliable as certificats can be shared and not related to the actual websites categories, but that seems not work either,.

Even following the famous white paper that was written for 80.10 that suggested to add those command

fw ctl set int urlf_use_sni_for_categorization 1

fw ctl set int urlf_block_unauthorized_sni 1

Of course our configuration is following the documentation, and HTTPS website categorization options is checked.

in Some cases they are even some silent drops (which i think is a separate) issue

@;6279018;[vs_2];[tid_11];[fw4_11];fw_log_drop_ex: Packet proto=6 2.17.5.196:443 -> 10.160.35.190:50092 dropped by fwmultik_process_f2p_cookie_inner Reason: PSL Drop: TLS_PARSER

There is some SK about this error for a special hotfix

TAC support case 7h tshoot couldn't find anything (not even this hotfix.

Any toughts ?

Kr,

Khalid

[PhoneBoy]

SNI verification (and inspecting based on SNI) requires HTTPS Inspection to be enabled in R80.30.
Enable HTTPS Inspection with a simple "Any Any Bypass" rule and try again.

[Khalid_Aftas]

i enabled https inspection with any any bypass.

It seems to be better, but i still have cases where is being droped and not matching the rule it should, with logs like this

this is case as test is a rule any any with Financial Services as category, and this website is in that category based on checkpoint tool to check.

@;888290;[vs_2];[tid_4];[fw4_4];fw_log_drop_ex: Packet proto=6 194.79.41.46:443 -> 10.160.35.190:61925 dropped by fwpslglue_chain Reason: PSL Reject: TLS_PARSER;
@;888290;[vs_2];[tid_4];[fw4_4];fw_log_drop_ex: Packet proto=6 194.79.41.46:443 -> 10.160.35.190:61925 dropped by fwpslglue_chain Reason: PSL Reject: TLS_PARSER;
@;888290;[vs_2];[tid_4];[fw4_4];fw_log_drop_ex: Packet proto=6 194.79.41.46:443 -> 10.160.35.190:61925 dropped by fwpslglue_chain Reason: PSL Reject: TLS_PARSER;

it's the in the other direction..

site is nbs.rs if you want to check certificat.

[PhoneBoy]

Looks similar to: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
I would get the TAC involved here.

[Khalid_Aftas]

Yeah that is what we found, and we were in a session with TAC (india) they did not find that hotfix...

[PhoneBoy]

TAC can request a portfix if required.
That said it may not be the exact same issue, so additional debugging may be required.

[Khalid_Aftas]

The issue was that Trusted CAs was not up to date, r&d was able to pinpoint it with the debugs.

Thx a lot for the help 😉

Enabling https inspection with any any bypass and updating Trusted CAs must be added in the documentation, that would avoid trouble like this for other clients 🙂

[Michael_Thompso]

Is there a way to verify that checkpoint is using sni versus just checking the CN in the certificate. Also how do you update the trusted CA?

[Khalid_Aftas]

Depending on your version, as of r80.30 SNI check are per default, but you NEED https inspection to be enabled, even without using it.

To update Trusted CA list, is under smartconsole, https inspection console, you have a big tab Trusted CA list, and a check box to look up for update, check it save, close, go back at it again and it should find new one, update and push policy

[Michael_Thompso]

Thanks .. do you still need "Categorize HTTPS websites" checked?

[Khalid_Aftas]

yes it's a requirement.

[PhoneBoy]

Note that the requirement to have HTTPS Inspection enabled for SNI support applies to R80.30 only, it is not required for R80.40 and later releases.
In this case, you can just set an "Any any bypass" rule as the HTTPS Inspection rulebase.
It does require "Categorize HTTPS Websites" to be checked as well, regardless of the release.

[TomaszSZ]

Hi All,

I have similar problem with URL Filtering. After read this article https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... , I upgrade cluster to 80.40 software, and 83 jumbo. The problem is still exist. Do you have some idea what's is wrong?

We do not use SSL insepction. The certificate list is ok. 

[_Val_]

Please elaborate on your "similar problem"