Blocking pornography without https inspection

[ED]

Hi,

Trying to block pornsites like Youporn fails without https inspection in R80.10. 

"Categorize HTTPS websites" is enabled. Youporn use a *.youporn.com certificate.

Is it true that Application control will not be able to block Pornography category for all sites that use a *.xxxx certificate?

[Vladimir]

Do you have the APPC/URLF enabled, added to the layer and are blocking the category "Pornography"?

Any chance a higher rule permitting it?

[ED]

APPC/URLF enabled added as to the layer and blocking category "Pornography". 

If https://youporn.com is used there is no match for that rule in the Application layer and it's being accepted by the default allow in the end of the application rules. 

If http://youporn.com is used it's being blocked. 

Do you think the *.youporn.com certificate is the problem?

[Vladimir]

Nope, I think it is a categorization problem. Please report it to Check Point. 

[Wolfgang]

checked on R80.20, is blocked

[Vladimir]

Then perhaps the exception categories should be examined.

[ED]

Thanks for checking Wolfgang. I hope someone can check it also in R80.10 without https inspection. 

[Wolfgang]

checked with R80.10, blocked without HTTPS inspection

[ED]

Wolfgang, thanks again for checking. Does R80.10 support having both HTTPS inspection and "Categorize HTTPS websites" enabled concurrently? When you tested did you have both enabled (without having your source machine going through HTTPS inspection?

[KennyManrique]

Hi Ed,

We're also experiencing this issues on R80.20 for pornography sites hosted on cloudflare. HTTPS categorization is enabled, but the site is not recognized under HTTPS. We opened a TAC case for another customer on R80.10 with this issue also, and the only viable solution is to enable HTTPS Inspection based on sk121532.

Our policy it's configured to block uncategorized and porn sites; however since the site on HTTPS returns cloudflare certificate, the connection is allowed on second instance:

Here is the DNS Query for the site:

You can check the alternate names on the site to get other porn sites that are hosted under the same cloudflare certificate; also not blocked.

[Timothy_Hall]

Right, the reason that full HTTPS Inspection must be enabled in that case is that the server's certificate name/subject does not match the actual domain/website being requested by the user.  In R80.30 it is planned to be able to leverage the Server Name Indication (SNI) provided by the client for filtering, instead of what the server's certificate says.  Should definitely help with this particular situation.  I think there may be a special version of R80.20 that supports SNI inspection as well.

[HeikoAnkenbrand]

The following is new in r80.30:

- SNI Support

- TLS1.3

Regards

Heiko

[Vladimir]

Hmm.. Tim, I think I may be missing something here:

The URL itself contains the word "porno".

We may surmise that the back-end categorization of sites would parse it out, we'll have the regex match for the categorization and would prevent even the DNS portion of communication.

So why are we even performing lookup of this URL's IP, connecting to it, analyzing its certificate etc.. ?

[PhoneBoy]

While some have said blocking the DNS lookups is a solution, it’s not full proof either. What if the DNS lookup doesn’t go thru the security device? Or traverses a DNS over HTTPS proxy like CloudFlare operates?

Having proper support for SNI is definitely going to help here.

[Vladimir]

Of course relying strictly on DNS is not a solution, for all we know the site could have a URL of "https://www.cakebaking.com" and be a porn site. The issue with Cloudflare is also a possibility, albeit is not a prevalent situation yet. That being said, if we do see the URL in the clear and if the portion of its name does clearly indicate its intended use, why not take advantage of it at this early stage and forego additional processing just to block it?

I also wander if in this case, the categorization is st to "Hold":

And if this will help.

[Timothy_Hall]

Doesn't matter if the URL requested by the client contains the word "porno", that is not what the firewall is looking at for categorization.  It is looking at the site name in the certificate sent by the remote server, which does not necessarily match the site name requested by the client.  This difference is what will be addressed by SNI inspection.  Some large social media companies have taken advantage of this difference in an attempt to avoid filtering and keep their users engaged 24/7 even at work where the site is supposed to be blocked.  All "to help ensure the privacy of their users".  Yeah right...

[Vladimir]

What about http:// sites?

I mean what is wrong, conceptually, with the idea of categorization based on the content of the site's name in addition to the SNI? In the end, it is looking at the strings identifying the sites, it is just in case of SNI inspection it is retrieving them from the certs.

[Boris_Karnaukh]

I had once similar issue. In my case HTTPS access to porno worked because there was an Application Control rule with "SSL Protocol" allowed.

[D_W · Accepted solution]

Any chance you have HTTPS Inspection active for testing/only for specific sources?
Or do you use a proxy?

Then HTTPS Categorization will not work in R80.10.

See:

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

Spoiler

The Categorize HTTPS sites option does not run if:

• HTTPS Inspection is enabled - solved in R80.20 and above under PMTR-3908
• There is a proxy between the destination site and the Security Gateway (or the Security Gateway functions as a proxy)

[ED]

Hi D_W,

I have HTTPS inspection active for only specific sources and also categorize HTTPS websites enabled. Turned off HTTPS inspection and the App/URL now stops the porn sites. I have some questions left:

1. What is the reason that having both HTTPS inspection and categorize HTTPS sites doesn't work in R80.10?

2. If i had to choose only one of these in R80.10, forexample HTTPS inspection and turned off categorization of HTTPS sites. How reliable is the APP/URL blade to stop HTTPS sites that belong to pornography category without being HTTPS inspected?

@PhoneBoy  do you have any input on these questions? 

[PhoneBoy]

Using HTTPS Inspection and HTTPS Categorization together is a long-standing product limitation we resolved in R80.20.

HTTPS Inspection is almost always going to give you a more reliable categorization result. In releases with SNI support (R80.30 or one of the customer releases that has it), the delta between the two will be less.

[Wei_Jie__Ho]

I am having a issue with URL Categorization. Can i clarify when HTTPS Categorization is turned on and i visit a website for example https://www.check4d.com, will the URL filtering check the URL https://www.check4d.com OR the CN of the certificate of the server. The snippet below shows the cert CN = sni172113.cloudflaressl.com. When this URL is keyed into URL categorization , it shows the category of "Computers/Internet". When i key in https://www.check4d.com, it shows category of "Gambling". Tried playing with the rules of blocking Computers/Internet, it works. But when I block category "Gambling" it went through. So I am assuming the URL Categorization is taking the CN url which is SNI172113.clodflaressl.com? Please advise. Thanks all.

[PhoneBoy]

You've described accurately what's happening. Support for SNI will mitigate this.

[HeikoAnkenbrand]

There is another way to block https pages without https inspection by doing this via DNS. Unfortunately this is not possible with Check Point technology. So I don't want to go into more detail here. When I have this requirement in projects, I use a product that does that at DNS level. 

Either it returns the original IP address of a DNS request or for dangerous content, a fake IP address of a blockpage page is returned. 

I will not write the manufacturer name in this forum:-)

Search goggle for "opendns umbrella"

[PhoneBoy]

And like I said, it's not 100% foolproof. And there are other providers that provide similar functionality.

[Vladimir]

If you recall, I've brought this subject up in our meeting with Top Brass, but am not sure if it registered. The idea is not that this single method must be 100% foolproof, but that it works when it otherwise does not and reduces the workload of the gateways while at it.