Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
ED
Advisor
Jump to solution

Blocking pornography without https inspection

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?

 

 

 

 

1 Solution

Accepted Solutions
D_W
Advisor

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...

Click to Expand

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)

 

View solution in original post

0 Kudos
26 Replies
Vladimir
Champion
Champion

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

Any chance a higher rule permitting it?

 

0 Kudos
ED
Advisor

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?

0 Kudos
Vladimir
Champion
Champion

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

0 Kudos
Wolfgang
Authority
Authority

checked on R80.20, is blocked

HTTPS_inspection_1.png

Vladimir
Champion
Champion

Then perhaps the exception categories should be examined.

0 Kudos
ED
Advisor

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

0 Kudos
Wolfgang
Authority
Authority

checked with R80.10, blocked without HTTPS inspection

https-inspection_R80.10.PNG

ED
Advisor

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?

0 Kudos
KennyManrique
Advisor

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:

imagen.png

Here is the DNS Query for the site:

imagen.png

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.

0 Kudos
Timothy_Hall
Legend Legend
Legend

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
HeikoAnkenbrand
Champion Champion
Champion

The following is new in r80.30:

- SNI Support

- TLS1.3

Regards

Heiko

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
Vladimir
Champion
Champion

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
Admin
Admin
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
Champion
Champion

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":

image.png

And if this will help.

0 Kudos
Timothy_Hall
Legend Legend
Legend

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...

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Vladimir
Champion
Champion

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.

 

0 Kudos
Boris_Karnaukh
Participant

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

0 Kudos
D_W
Advisor

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...

Click to Expand

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)

 

0 Kudos
ED
Advisor

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? 

 

0 Kudos
PhoneBoy
Admin
Admin
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.
0 Kudos
Wei_Jie__Ho
Employee
Employee

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.

 

Cert.PNG

0 Kudos
PhoneBoy
Admin
Admin
You've described accurately what's happening. Support for SNI will mitigate this.
0 Kudos
jomac
Explorer

We're also experiencing this issues on R80.20 for pornography sites or gambling sites hosted on cloudflare, for example http://13.228.235.219/ .  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.

0 Kudos
HeikoAnkenbrand
Champion Champion
Champion

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"

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
0 Kudos
PhoneBoy
Admin
Admin
And like I said, it's not 100% foolproof. And there are other providers that provide similar functionality.
0 Kudos
Vladimir
Champion
Champion

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events