I can't block a domain with blade APPC+URLF

[Matlu]

Hello, everyone.

I have a problem to get a particular domain locked through the APPC+URLF blades (which are working on a separate layer).

The domain is https://calibre-ebook.com

According to the following Checkpoint page, https://urlcat.checkpoint.com/urlcat/main.htm
This page belongs to the group "Computers / Internet", but even blocking this group, the page still "loads" (I show the image of how I have configured my rule).

In the same rule, I have created a custom group, which is called "Personalizado", where I have put the domain with special characters, but still, I can not block the page.

Can you tell me, if in these scenarios, it is mandatory to have the HTTPS Inspection enabled to block certain pages?

Because for some others the rule is working, but for this domain, I can't block it.

Thanks for your support.

[PhoneBoy · Accepted solution]

The answer is: it depends on:

• The version/JHF level you're running
• The certificate used on the website (whether or not the site name is encoded in the CN or is provided through SNI)

The site in question is using Let's Encrypt for its certificate and is using SNI. 
The behavior suggests:

• You're on a release prior to R80.40
• You have Categorize HTTPS Sites disabled

R80.40 and above includes support for Verified SNI if Categorize HTTPS Sites is enabled (should be by default).
In R80.20 and R80.30 (which are End of Support, FYI), you need to have HTTPS Inspection enabled (can be just with an "any any bypass" rule) for Verified SNI to function correctly.
In earlier releases, HTTPS Inspection must be enabled and fully configured when a site is identified only by SNI in the certificate.
See also: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Matlu]

Hello,

Indeed, my GW is working on version R80.30, and it does not have HTTPS Inspection enabled.
So, according to your comments, in my environment, it is necessary to work with HTTPS Inspection, right?
Can I do it with Checkpoint's "SELF-SIGNED" Certificate?

Sorry, but what do you mean by the acronym "SNI"?

Thanks for your comment.

[_Val_]

SNI - Server Name Indication. It can be used for the categorization of URLs with SNI verification technique, i.e. HTTPSi lite. 

On R80.30, however, SNI verification is not working if HTTPS Inspection is not enabled. Most importantly, R80.30 is out of support.

[Matlu]

I understand the scenario better, but I have some concerns.

All web pages do not always use a SNI (at least when they use the https service), right?

If I enable HTTPS Inspection, I run the risk of having a high demand on my computer's resources?

How can I identify if a web page that works in https, is with SNI in its certificate?

Is there any example to be able to realize this, please.

Maybe this is why I can't block certain domains.

Thank you.

[the_rock]

Well, see, its sort of "catch 22" as they say. Yes, enabling https inspection may impact performance, but, if you have a "beefy" firewall, you may notnotice much difference at all. All these things you have concern about would work fine with inspection on.

[PhoneBoy]

This is the precise the reason you cannot block certain sites.
You can determine if a site is using SNI or not by reviewing the TLS certificate in the browser.
This is typically done by clicking the lock icon in the browser next to the URL.
For example, review the certificate for this very site:

You'll notice that instead of listing community.checkpoint.com...it lists something else.
In many cases (for example, the various Google services) also use the same certificate.
This makes it difficult to block access to, say, YouTube, without also blocking access to Google Search. 

HTTPS Inspection does demand additional resources, yes.
However, the impact should be minimal if you simply use an "any any bypass" rule as your only rule in the HTTPS Inspection policy since no traffic will actually be decrypted.

Again, it is highly recommended to upgrade from R80.30 since it is End of Support.

[Matlu]

Thanks for your comments.

So, I should enable the HTTPS Inspection in my old version of GAIA and apply a general rule of "Bypass" type to try not to increase the performance of my GW, right?

Looking at the image of the example you share with me (community.checkpoint.com), I understand that having the result in the certificate highlighting the domain "secure07.lithium.com", this already tells us that this site (service) is using a SNI.

Is this correct?

Thanks for everything.

[the_rock]

Great explanation as always by @PhoneBoy . Also, think of  it this way...SNI cert would represent multiple domains that resolve to same IP address. So, if you look at cert for google.com and youtube.com its exact same thing.

[Matlu]

Buddy,

Not all web services that are public on the Internet, use this "SNI" theme, right?

Checkpoint has a page to know to which category a URL belongs, but now I see that this is not enough to be able to block a "content", since I will have to "observe" if the page uses a SNI or not.

It seems that only big companies, like Youtube, Facebook, Google, and some "peculiar" sites decide to work with this SNI.

Greetings.

[the_rock]

Correct, but thats why you need https inspection, as then SNI verification will work as intended, meaning since its extension of TLS, end users will always be verified to see correct SSL cert of the site they are accessing.

[Matlu]

Hello, Roca.

In your experience, what is the best way to lock a particular domain?
Do you use special characters to block them?
I am already working with HTTPS Inspection [Checkpoint's self-signed], and so far so good.

I have the doubt, because I have a custom rule and inside the category that I have created, I have added to the domain "marca.com", so that it is blocked, but the page continues to open.
Do you block the domains with a particular way of registering them?
Do you use special characters or something?

Greetings.

[the_rock]

So what I do in case like that is this...say you want to block ANYTHING marca whatever, just create custom app site and add *marca*, thats it, works 100$ of the time. Then, put it in relevant rule, push policy and thats it.

[Matlu]

Buddy,

I will try it and let you know how it goes.

In these scenarios you recommend, the checkbox "URLs are defined as Regular Expressions" should remain unchecked, is that correct?

If I want to block also the Checkpoint page for example, hahahahahahahah.

The domain "community.checkpoint.com" in my custom app site, it occurs to me that applying your recommendation, it would be something like this: *community.checkpoint.com*.

Am I right?

Only the checkbox remains as a doubt.

Thanks for your support.

[the_rock]

Yes, correct! By the way, I NEVER check that option for regular expression and the way I told you in my previous response works every single time, so why "fix it if it aint broke" as they say : - )

[Matlu]

The_rock

Friend,
Your theory is correct, so far, it's working fine for me, except that for a new domain, I'm having "problems" with the theory you gave me.
It is for this domain -> https://get.adobe.com/es/reader/

I am applying your recommendation, but still, the page keeps loading, when it should be blocked with my explicit rule (I share some images with you).

On the way to this post, I noticed another error, haha.
It gets fun.

Now I've noticed that I've lost the management to access via WebUI to my GW and it seems very strange to me.
As a test, I have created a rule just for my GW in the HTTPS Inspection, without success.

Does it have to do with having enabled HTTPS Inspection in the old version of GAIA? R80.30 with JHF Take 255.

I will keep checking these issues, maybe I am doing something wrong.

Thanks for all your help,

[the_rock]

Dont do it like that, just do *adobe* if you want to block ANYTHING adobe related. I cant comment on your 2nd question, as there are not too many details about it, but as phoneboy said, R80.30 is not supported any longer anyway, plus, besides that, another incentive to upgrade is that in R81.10, https inspection is wayyyy better.

[Matlu]

It is a fact, that we are going to migrate, these versions are very old and give many problems.
We are just waiting for the client to define the dates of the window.

Regarding my second question, I was referring to the fact that I have lost access to my Gateway through the WebUI.

I don't know if this is related to having enabled HTTPS Inspection, I have the impression that it is.

I can't access the Gateway via CLI either, only via console.
Can HTTPS be the cause of losing the web management of your Gateway?

Greetings.

[the_rock]

Um, does not make much sense that enabling https inspection would cause that, never seen it happen in al my years with CP. What do logs show, as to why it fails? Maybe also do zdebug and check, it would be easiest way to confirm, for sure.