- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Blocked Porn is getting through!
Options
- 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?
×
Sign in with your Check Point UserCenter/PartnerMap account to access more great content and get a chance to win some Apple AirPods! If you don't have an account, create one now for free!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jump to solution
Blocked Porn is getting through!
Hi
As you can see the web page www.superporn.com only as an example, many other porn websites bypassing the same!
was blocked only for 2 logs and then it was accepted all the way!
I wonder why would that happen
The blocking rule is app/url rule:
as you can see above sex and pornography are blocked, but still can be accessed. I have tested 3 different computers and all got some drops by that rule but then they could bypass it!?
Any ideas?
3 Solutions
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Atleast part of the answer is in the log output provided.
QUIC traffic is allowed in your environment and this cannot be inspected.
For now you can block it and it will force it to use HTTPS instead.
CCSM R77/R80/ELITE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By any chance the issue is occurring only on Chrome/Edge browser just recently?
We have a similar issue with HTTPS categorization since last week right after the Chrome/Edge version was upgraded to 124, where TLS1.3 handshake is not detected by URL Filtering, and sites are somehow not blocked. This does not occur with Firefox or other browsers.
The issue didn't occur in Chrome ver.123
Usually HTTPS categorization should work with TLS1.3, but somehow its not working since the browser update.
As a workaround, we have disabled the following option in chrome, and sites are able to be blocked by the access policy as before.
chrome://flags or edge://flags
-> TLS 1.3 hybridized Kyber support
I saw some discussions on other forums, that this parameter is affecting URL/content filtering for other vendors like Fortinet and SonicWall.
https://www.reddit.com/r/sysadmin/comments/1carvpd/chrome_124_breaks_tls_handshake/
https://www.sonicwall.com/support/knowledge-base/websites-randomly-gets-blocked-or-allowed-with-no-c...
Any other people experiencing a similar issue?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just to share with the community... it looks like a SK was published regarding this issue with chrome "TLS 1.3 hybridized Kyber support". For those who are experiencing this issue with HTTPS categorization, and like to resolve this without activating Full SSL INS, I would recommend to open a ticket to TAC to receive a hotfix, both for Gaia and Gaia Embedded 🙂
"Categorized HTTPS Sites" stopped to classify specific websites
https://support.checkpoint.com/results/sk/sk182318
61 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Atleast part of the answer is in the log output provided.
QUIC traffic is allowed in your environment and this cannot be inspected.
For now you can block it and it will force it to use HTTPS instead.
CCSM R77/R80/ELITE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
what about all other websites that use Quic protocol? If I block it ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You need to make an exception in https policy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
what if HTTPS inspection is not active. How to check if our appliance is able to do it or not?
The porn websites still open through HTTPS.
I did add QUIC protocol to the blocked list as you mentioned but now porn websites are using HTTPS instead!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have 'Categorise HTTPS sites' enabled in the URLF blade settings?
If you aren't doing HTTPS inspection, the gateway can't see the HTTP header to see the URL in it, so we have to rely on the CN in the cert. I don't know how many porn sites put their full URL in the cert but you might have to check and see what it says if it's still getting through.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
it is enabled!
Should I add something to the blocked list?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, how could my gateway detect and block traffic that's included in the block list before the new Chrome/Edge update (124)? I mean, we've never used HTTPS before!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's not specific to the sites rather QUIC more broadly, there is an SK that describes the need to mitigate this (see sk108202 / sk112249 / sk111754).
In R82 and above we will introduce support for QUIC / HTTP3 inspection.
CCSM R77/R80/ELITE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
Having read this thread , i would like a little clarity on this please.
So since v124 of Chrome / Edge... blocking QUIC and using HTTPS categorisation is not enough for these browsers traffic to get correctly handled by URL filtering blade etc ?
The only solution - without modifying the browser settings so far is to use R81.20 and HTTPS Inspection ? or have I mis-read some of the replies ?
Please clarify so we can implement the best solution going forward
thanks
Peter
- 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
There is no general change in recommended best practice.
The only variable is the experimental setting recently introduced in Chrome based browsers. I'm sure once TAC has a position on this an SK will be published if deemed appropriate.
R82 introduces support for QUIC inspection, recommendations will likely be updated then with that in mind.
CCSM R77/R80/ELITE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey Chris,
Correct me if Im wrong when I say this, but Im sure even in R82 people will need to use https inspection to properly block QUIC protocol?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've not yet been fortunate to experience the EA for R82 so can't comment on how the configuration of the QUIC inspection looks.
CCSM R77/R80/ELITE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Fair enough...if you find out and are allowed to share, please do.
Best,
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just add custom category *superporn* and that will fix it, for sure.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
K, I was wrong, wont be first or last time lol
@Chris_Atkinson is 100% right. I tested in the lab and as soon as I added quick udp and quic protocol to be blocked, worked as expected, just restarted my browsers and page was blocked, but BEFORE I added quick in the rule below, it was allowed.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By any chance the issue is occurring only on Chrome/Edge browser just recently?
We have a similar issue with HTTPS categorization since last week right after the Chrome/Edge version was upgraded to 124, where TLS1.3 handshake is not detected by URL Filtering, and sites are somehow not blocked. This does not occur with Firefox or other browsers.
The issue didn't occur in Chrome ver.123
Usually HTTPS categorization should work with TLS1.3, but somehow its not working since the browser update.
As a workaround, we have disabled the following option in chrome, and sites are able to be blocked by the access policy as before.
chrome://flags or edge://flags
-> TLS 1.3 hybridized Kyber support
I saw some discussions on other forums, that this parameter is affecting URL/content filtering for other vendors like Fortinet and SonicWall.
https://www.reddit.com/r/sysadmin/comments/1carvpd/chrome_124_breaks_tls_handshake/
https://www.sonicwall.com/support/knowledge-base/websites-randomly-gets-blocked-or-allowed-with-no-c...
Any other people experiencing a similar issue?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
According to the TLS support SK, TLS 1.3 is only supported in HTTPS Inspection when the gateway is running in User Space (USFW)
TLS SK: https://support.checkpoint.com/results/sk/sk178505
USFW SK: https://support.checkpoint.com/results/sk/sk167052
So enabling USFW might be worth a test for you.
If you're not doing HTTPS Inspection and just doing Categorise HTTPS sites, TLS 1.3 should work in all current versions. https://support.checkpoint.com/results/sk/sk163515
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What if our appliance (6500) does not support USFW?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
All 6000 appliances support USFW and should be enabled by default in current versions. The commands to double check are in the SK there.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here are my firewall stats:
Accelerated conns/Total conns : 161/53539 (0%)
LightSpeed conns/Total conns : 0/53539 (0%)
Accelerated pkts/Total pkts : 27688409458/30831725989 (89%)
LightSpeed pkts/Total pkts : 0/30831725989 (0%)
F2Fed pkts/Total pkts : 3143316531/30831725989 (10%)
F2V pkts/Total pkts : 145057135/30831725989 (0%)
CPASXL pkts/Total pkts : 1297843673/30831725989 (4%)
PSLXL pkts/Total pkts : 24911653523/30831725989 (80%)
CPAS pipeline pkts/Total pkts : 0/30831725989 (0%)
PSL pipeline pkts/Total pkts : 0/30831725989 (0%)
QOS inbound pkts/Total pkts : 0/30831725989 (0%)
QOS outbound pkts/Total pkts : 0/30831725989 (0%)
Corrected pkts/Total pkts : 0/30831725989 (0%)
what is the recommended mode? KSFW or USFW
We are running KSFW today
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The recommendation in that case is USFW.
In general, we recommend USFW over KMFW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So just for confirmation:
- HTTPS inspection is not used.
- Categories HTTPS sites is enabled
- Firewall mode is KSFW.
If moving from KSFW to USFW would solve the problem ?
is there any known limitation of USFW that we need to know about?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am not aware of any issues, plus USFW is default anyway if I recall.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We only have HTTPS categorization enabled on R80.20.XX and R81.10.XX on locally managed SMB firewalls.
The issue does resolve with latest Chrome version if we enable Full SSLINS, but the majority of our customers do not use SSL Inspection.
Btw, there is no way to enable USFW on Gaia Embedded currently(I believe its not supported...) Force setting kernel parameters did not work for us either.
As I mentioned, this issue does not occur on TLS1.3 handshakes in the old Chrome/Edge version 123, I'm assuming the behavior changed in version 124 which the site could not be detected by URLF blade for some reason, unless we disable the problematic option in the browser.
I'm not sure if this behavior is something to be reviewed on the browser side (like a bug?), or something firewall vendors may need to follow to support the default behavior on the new chrome/edge version...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think you have right here:
I tested Firefox and all porn websites are blocked.
Tested also Edge and Chrome and both are allowing porn websites
Edge version: 124.0.2478.51
Chrome version: 124.0.6367.92
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The issue will likely persist to a degree if you don't also handle the QUIC traffic.
CCSM R77/R80/ELITE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did blocked QUIC:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Great, just validate that you see the UDP/443 traffic blocked in the logs.
Depending on your policy structure you may benefit from service level blocking in the access policy.
CCSM R77/R80/ELITE
Blocked Porn is getting through!
Hi
As you can see the web page www.superporn.com only as an example, many other porn websites bypassing the same!
was blocked only for 2 logs and then it was accepted all the way!
I wonder why would that happen
The blocking rule is app/url rule:
as you can see above sex and pornography are blocked, but still can be accessed. I have tested 3 different computers and all got some drops by that rule but then they could bypass it!?
Any ideas?
