White Paper - URL Filtering using SNI for HTTPS websites

[_Val_]

Author

@Kevin_Jones 

Abstract

The document describes how to leverage Server Name Indication (SNI) when using URL Filtering Software Blade.

For the full list of White Papers, go here. 

[Vladimir]

@Kevin_Jones , thank you for a brief and concise document describing SNI filtering functionality. Many of my clients can benefit from reading it.

In regards to its general availability: your document is from December of last year. When is this functionality will be available in R80.20 by JHFA?

Thank you,

Vladimir

[Uri_Lewitus]

R80.30

[MikeB]

Is this functionality will be available in R80.20 by JHFA???
Considering right now R80.20 is the recommended version

[saulomendonca]

Is that available in R80_10_JUMBO_HF?

[Martin_Valenta]

And SNI visibility with tls 1.3?

https://blog.cloudflare.com/encrypted-sni/

[Uri_Lewitus]

For URL filtering this is on by default
I am told that NG bypass does not require any extra configuration I am still validating

[Vladimir]

@Uri_Lewitus , did you get the chance to validate this?

Thank you,

Vladimir

[RickLin]

Can CheckPoint teach us how to use "Next Generation Bypass"? 

Thanks for clarification.

[G_W_Albrecht]

That is part of this White Paper - URL Filtering using SNI for HTTPS websites !

[saulomendonca]

Is this functionality already available in R80_10_JUMBO_HF?? thanks

[Eduardo_Pereira]

As of now, this is a separate HF that goes on top of T154.

[FedericoMeiners]

Great information!

I have two qustions:

1) Can anyone confirm is the following feature is included in the new engine of SSL Inspection in R80.30? R80.30 doesn't need the probe bypass feature since it checks de Client Hello and the certificate. Also, it works with Categorize HTTPS without SSL Inspection and without turning on the kernel parameters? I'll try to check this later in a lab enviroment.

"Using this field, rather than relying on the CN of the certificate, gives more specific and accurate information about the requested site. The recently released hotfix for Check Point R80.10 gateways does change this behavior and utilize the SNI extension for categorization. Once installed, the feature can be enabled with the following command: fw ctl set int urlf_use_sni_for_categorization 1 This hotfix also allows a further check to make sure that the SNI requested by the client matches one of the SAN entries on the certificate. To enable this feature, use this command: fw ctl set int urlf_block_unauthorized_sni 1"

2) Is there any benefit in having "Categorize HTTPS sites" AND Outbound SSL Inspection? There are many posts that state that they are mutually exclusive, but in R80.20+ you can have both turned on. So far in my testing I could not see any benefits. Maybe it doesn't inspect all the https traffic?

Thanks!

Federico Meiners

[Vladimir]

@FedericoMeiners , the SSL categorization is there simply to improve the Application Control and URL filtering. SSL inspection actually allow the payload to be analyzed by other TP blades as well as Content Control and DLP.

[FedericoMeiners]

@Vladimir I know that, but what is the effect/advantage of having Outbound SSL Inspection + HTTPS Categorization? You can turn them both in R80.20+

[Vladimir]

Consider, for instance, the situation when you are exempting certain traffic from SSL inspection based on its categories, i.e. financial and health.

[_Val_]

I see here many questions about SNI enhancement availability with R80.20.

As fas as I am concern, R80.20 can have SNI functionality back-ported, with a special HFA, with is not part of the regular Jumbo. 

@Oren_Segev, can you please give more details?

[saulomendonca]

Could someone please confirm if this functionality works on R80.20? thanks

[MikeB]

Any idea when this functionality (URL Filtering using SNI for HTTPS websites) will be available for Gaia Embedded (7xx/14xx)?

[Tom_Hinoue]

Hi Miguel,

In matter of fact, SNI for APPI/URLF it is already available on Gaia Embedded on recent firmwares (disabled by default) in locally managed mode.

Go to Device -> Advanced Settings and find [Application Control and URL Filtering - Custom App over HTTPS].
Enable the parameter and you're good to go.

[MikeB]

Thanks @Tom_Hinoue!
What about centrally managed mode?

[FelipeTropeia]

Hi @Tom_Hinoue ,

Which version are you running on this picture? 

I'm running Embedded GAIA R77.20.87 - Build 960 and I wasn't able to see this parameter Custom App Over HTTPS as shown below 

[Tom_Hinoue]

Hi @FelipeTropeia,

This feature is only available currently on Locally Managed mode of SMB appliances since R77.20.80+, and not Centrally Managed mode as what I believe you are using now from your provided image. (and apologies to @MikeB for missing your post)

From what I know that SNI is available on R80.10+ in latest Jumbo Hotfixes on maintrain, I believe SNI on Centrally Managed Gaia Embedded which runs on R77 code is not compatible with SNI inspection yet (some one correct me if I'm wrong)

Staring the new 1550/1590 the OS now runs on R80.20 code, so maybe we can expect SNI for Centrally Managed soon 🙂

[Luis_Romero]

https inspection needs to be enabled for sni to work?

[MikeB]

as far as I could read...Yes, you must enable HTTPS Inspection for SNI to work.
You can simple enable HTTPS Inspection with a rule to bypass all (any any bypass)

[HristoGrigorov]

SNI support for Site Categorization

Starting from R80.30, a new functionality allows the categorization of HTTPS sites before the HTTPS Inspection begins, and prevents connectivity failure if the inspection does not succeed.

SNI is an extension to the TLS protocol, which indicates the hostname at the start of the TLS handshaking process.

The categorization is performed by examining the SNI field in the client hello message at the beginning of the TLS handshaking process. To make sure that you reached the right site, the SNI is verified against the Subject Alternative Name of the host, which appears in the certificate.

After the identity of the host is known and verified, the site is categorized, and it is determined whether the connection should be inspected or not.

SNI support is enabled by default.

[_Val_]

Small correction. SNI works out of the box event without enabling HTTPSi on R80.40. On R80.30, you have to enable HTTPSi for it to work. 

[Martin_Valenta]

so for firewall with r80.30 we should add https inspection layer on policy and set rule in this layer with action bypass for with any source and destination?

[_Val_]

Correct. As already mentioned above by @MikeB 

[Tobias_Moritz]

For anyone reading this white paper and Checkmates thread and believes (like me) you are all good with R80.40 without HTTPS Inspection policy and blade at all

- or with other words -

When you want to use only "HTTPS Inspection Light", which means you enabled "Categorize HTTPS sites" checkbox in URL Filtering blade settings:

Let me give you this litte hints:

• Gateway is watching the TLS handshake (not intercepting it, because we don't use full HTTPS Inspection). I guess this is done by CPAS.
• If Gateway sees problems in this TLS handshake, connection may be permitted (depending on your policy), but certificate information is not used for site categorization by URL Filtering blade. You will see a log entry of type Detect from URL Filtering blade, telling you about the problem, your gateway has with this handshake. There is no hint in the log, that site categorization by URL Filtering blade is limited because of this problem.
  • If you retry the connection attempt, please take care: you will get only one log entry of this type with the first try, because site categorization will be cached in table cptls_host_name_cache.
  • Problems could be
    • Expired certificate
    • Revoked certificate
    • Untrusted CA
• While expired certificate and revoked certificate are easy to understand, the part with untrusted CA is interesting. While we are NOT intercepting TLS handshakes by NOT using HTTPS Inspection blade, the gateway still verifies the server certificate against its own HTTP Inspection trusted CA list. If this fails, URL categorization by SNI will not work.
• So when you (like me) never checked HTTPS Inspection blade settings in old SmartDashboard (still not migrated to SmartConsole in R80.40), you might not notice, that the Trusted CA list is not up to date or does not contain the CA certificates you need.

You can learn about that in sk64521 and sk159872 which also tell you, that you have to take care of the site categorization cache (table cptls_host_name_cache) and the responsible deamon (wstlsd) yourself after fixing the Trusted CA list.

Update of the HTTPS Inspection CA Trust List is documented in sk64521, but this did not work on our side. SMS downloaded recent version 2.6 zip file sucessfully (month ago), but SmartDashboard did not show an available update. We have a TAC case running for this. Workaround: Download zip file from SMS to your client with scp or something and upload it manually using SmartDashboard.