- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: Blocking pornography without https inspection
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have the APPC/URLF enabled, added to the layer and are blocking the category "Pornography"?
Any chance a higher rule permitting it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nope, I think it is a categorization problem. Please report it to Check Point.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
checked on R80.20, is blocked
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Then perhaps the exception categories should be examined.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for checking Wolfgang. I hope someone can check it also in R80.10 without https inspection.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
checked with R80.10, blocked without HTTPS inspection
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
now available at maxpowerfirewalls.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The following is new in r80.30:
- SNI Support
- TLS1.3
Regards
Heiko
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.. ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Having proper support for SNI is definitely going to help here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
now available at maxpowerfirewalls.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I had once similar issue. In my case HTTPS access to porno worked because there was an Application Control rule with "SSL Protocol" allowed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.