Chromium-based browsers (Edge, Chrome, etc) on Canary channel (v125) bypass content filtering/DPI
happy_harry
Newbie ✭
I've discovered Chromium browsers based on v125 and newer are able to bypass SonicWall's content filtering. I've tested this with SonicOS version 6.5 and 7.1.1.
This is an issue with Google Chrome Canary and Microsoft Edge Canary (v125), but not Dev (v124) so I believe this is a new problem specific to all Chromium browsers based on v125+.
On the firewall running 7.1.1, I also blocked QUIC using Application Control, which made no difference. To further verify this is not related to QUIC, I disabled QUIC in the browser settings, and blocked UDP on port 443.
In the case of the 6.5 firewall, DPI is disabled, but it is enabled with a certificate installed on my test machine on the 7.1.1 firewall.
HTTPS filtering is enabled on the filtering policy, and I'm not logged in as admin so that's not related either.
Filtering works correctly with Google Chrome Stabe and Beta, and Edge Stable and Beta, and the website certificates show that they are signed by SonicWall, which confirms the traffic is being decrypted. However, in Dev/Canary (v125), the certificates are the original website certs.
For my testing, I blocked the "Shopping" category, and tried browsing to Target.com. I've linked the cert info below.
Does anyone have any ideas? I've never seen this before, but it seems to be a recent development since I can only replicate it on v125.
Answers
Something I didn't notice before is that this seems to be only an issue when in Incognito Mode. Filtering seems to work correctly when not incognito.
@happy_harry I have the same problem with v124 Edge stable. Contentfilter and DPISSL no longer work - regardless of whether normal or incognito
I have noticed a different issue, it seems that somehow the firewall CFS service is blocking everything that we have been able to access in the past. Disabling QUIC makes no difference. It is happening on both Chrome and Edge.
Started in Chrome Version 124.0.6367.61 and in Edge Version 124.0.2478.51
I found the feature in Edge and Chrome: TLS 1.3 hybridized Kyber support But it must not happen that users can bypass DPISSL (or blocking). SonicWall must react quickly to this.
A commenter posted this on my /r/SonicWall Reddit thread about the issue. I can confirm it also fixes it on Chrome.
edge://flags/ ( for edge, change it from chrome to edge in the URL)Search and disable the following setting:TLS 1.3 hybridized Kyber support
For Chrome use "chrome://flags/"
Obviously this is a workaround, not a true fix. Hopefully SonicWall fixes this issue quickly.
thanks to Frederico on Google-Help:
to disabled TLS 1.3 hybridized Kyber support by GPO
Updating ADMX files for Edge and Chrome:
Computer Configuration > Policies > Administrative Templates > Google > Google Chrome > Enable post-quantum key agreement for TLS > Disabled
Computer Configuration > Policies > Administrative Templates > Microsoft Edge> Enable post-quantum key agreement for TLS > Disabled
Doing that, I do not have problems anymore and my Internet Filtering by CFS Sonicwall is working fine now
I can confirm we are using the same workaround with the GPO "Enable post-quantum key agreement for TLS" for both Edge and Chrome.
It seems to fix it for now, but I am sure it's temporary.
KB released:
https://www.sonicwall.com/support/knowledge-base/websites-randomly-gets-blocked-or-allowed-with-no-changes-made-after-browser-upgrades-v124/240422222041287/
Well, looking forward to a firmware fix or something on this now that I see a KB :)
Wouldn't it be great if the KB article mentioned that this is addressed in 7.1.1-7058?
It seems that KYBER is getting abandoned in the near Future (Nov 2024) with Chrome 131, hopefully SonicOS can keep up this time?
https://thehackernews.com/2024/09/google-chrome-switches-to-ml-kem-for.html
—Michael@BWC