Blocked Porn is getting through!

[Moudar]

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?

[Moudar]

As you can see below, QUIC is blocked, but that did not solve the problem, because all websites started to use HTTPS instead!

I wonder how to check if our 6500 is able to run HTTPS on all traffic? Any guide or how to ?

We have now disabled the "-> TLS 1.3 hybridized Kyber support" as @Tom_Hinoue  said and it works fine!

But what will the permanent solution be for this problem, if we cannot activate HTTPS inspection?

[the_rock]

Can you check how below is configured?

Andy

 

[Moudar]

[the_rock]

Fail mode is blocked by default, not allow.

Andy

[Moudar]

If I change to "block" should it improve blocking of what should be blocked ?

[the_rock]

Personally, I would leave it as default, which is block, because if there is an issue with URLF engine, site would be blocked, instead of allowed.

Andy

[the_rock]

Fail Mode

You can select the enforcement option to use if the Application and URL Filtering engine fails during inspection.

To select the enforcement option

1. Go to Manage & Settings > Blades > Application and URL Filtering > Advanced Settings.

2. In the Application Settings window, select one option:

   • Allow all requests (fail-open) - All traffic is allowed.

   • Block all requests (fail-close) - All traffic is blocked (default).

[Chris_Atkinson]

Noted, good to confirm the bases are covered.

Best to raise the specific questions about this browser options impact with TAC for review.

[Moudar]

What are the drawbacks of disabling the 'TLS 1.3 hybridized Kyber support' flag?

[Tom_Hinoue]

@Moudar 

I believe there are no specific drawbacks for disabling it, as it was originally disabled in the old version.

The option was added for chrome to use the X25519Kyber768 post-quantum secure key encapsulation mechanism for TLS connections to add layer to security by default. In chrome/edge this is used for both QUIC and HTTPS.

After doing some research, it seems the option to disable this flag in Chrome is scheduled to be removed by end of 2024,so WEB servers/devices are expected to be fixed to adapt to this new behavior.

This was a good article btw to understand what's going on.
https://www.bleepingcomputer.com/news/security/google-chromes-new-post-quantum-cryptography-may-brea...

@Chris_Atkinson
Being said, I believe HTTPS categorization on TLS1.3 should work without using SSL Inspection and it seems to me that the firewall is unable to inspect the SSL handshake when Kyber768 is used.
I'm assuming we can access the site because we have fail-mode enabled in the engine settings, and will get a connection-reset instead if we have the fail-mode configured to block all requests.

Does USFW have the capabilities to categorize this type of connection as we could before? (w/o using Full SSLINS)
If so, can we expect a hotfix for environments that cannot switch to USFW, like Embedded Gaia?

I could not find any Kyber related keywords in existing SKs or in R81.10/R81.20 releases notes that addresses such behavior.

Asking here because we have no response yet from TAC 🙂

[PhoneBoy]

Please send me your ticket in a PM.
I am checking directly with the relevant R&D team on this.

[Tom_Hinoue]

@PhoneBoy 
Thanks! Just sent you a PM.

[Chris_Atkinson]

@Tom_Hinoue I'm sure you have but please loop your SE in on the SR as well.

Thanks @PhoneBoy for the assist whilst I slept. 😉

[Tom_Hinoue]

Sure did, but thanks for the reminder 😉

[the_rock]

Hey @Moudar ...how did you make out with this? Any progress?

[Moudar]

Initially, I disabled the flag using GPO. Now, we've activated Cisco Umbrella to block what needs to be blocked via DNS.

In the meantime, I'll investigate the feasibility of deploying HTTPS inspection, in hope that HTTPS inspection will do the job when QUIC is blocked. 

[the_rock]

100% it will. But then if you think about it, there is probably less than 1% of http sites in the world nowdays, so it only makes logical sense to have ssl inspection turned on. I know people are worried about using more resources on the fw in that case and privacy reasons (and I get that), but honestly, even with other vendors, it does not "eat up" that much more power at all.

Best,

Andy

[Moudar]

I'm curious to understand how, in my specific situation, it worked prior to activating the flag on Chrome and Edge.

[the_rock]

Sorry, what flag are we talking about? 

Andy

[Moudar]

TLS 1.3 hybridized Kyber

[the_rock]

I see, right. Well, put it this way... I tested this in the lab with that setting as default, disabled, enabled, when https inspection is enabled, works regardless. As soon as I disable it, there is an issue.

Can you please describe EXACT scenario where site was blocked before? What were settings you had enabled? I am happy to try it in the lab myself.

Andy

[Moudar]

For your reference, all the details can be found at the beginning of this post

[the_rock]

I read your post very carefully since the beginning, but Im still not 100% clear on exactly what settings were enabled when you say this used to work and then all of a sudden broke. If you can confirm this, happy to test it in the lab.

Just working on some Fortinet stuff now, but if you clarify, I will test it in a bit.

Best,

Andy

[Moudar]

We use app/url to block porn and other things. 

Internal networks --> internet--> services and application as in the foto --> drop

[the_rock]

I know thats whats used, no worries, but my concern is, in engine settings under blade for url filtering, fail mode was allow, which in my opinion is incorrect, because say if there is engine "failure" for the blade, site will be allowed, rather than blocked. Are you able to change that back to fail-close instead, as per below?

Andy

 

[Moudar]

But if "block" is chosen and URL blade fails, then it will block anything not only these categories under services and application. Or do I miss something here?

[the_rock]

I believe, though I could be mistaken when I say this, it would generally apply to any categories subjected tu URLF rule(s).

Andy

[Alex_Lewis]

This site does an excellent job of explaining this flag and why some web applications/services are broke starting with Chrome/Edge 124:  https://tldr.fail/

[PhoneBoy]

Thanks for sharing that.
I suspect we'll fix this in an upcoming JHF.

[Tom_Hinoue]

@Alex_Lewis 
Yes, I came across that site while surfing online as well. Indeed it's good reference to understand the issue!

As PhoneBoy mentioned, it seems there maybe  need for some work done on vendor side to address the change.
Lets see what CP response would be 🙂