04-24-2024 06:27 AM
Hello
We have a lot of clients getting the following error when contacting diffrent sites: ERR_SSL_PROTOCOL_ERROR, we have read that SonicWall and Palo Alto also have these problemes. Solution is to turn off "TLS 1.3 Hybridized Kyber Support" in chromium web browser, and/or I have tried to disable all SSL and "Early application detection and URL categorization" for 1.3 in FirePower.
We are using fw: 7.2.5, have created a TAC case and are waiting for answer.
Anybody else getting this ?
Regards
J.
05-09-2024 11:39 AM
TLS 1.3 Hybridized Kyber Support Issue Affecting Browser Connections.
As many of you may have AnyConnect cases with a screenshot like the following. Complaining of SSL_Protocol_Errors. And a recent issue that has been identified with the latest Chromium update, which may be affecting your browser connections, particularly those involving Secure Assertion Markup Language (SAML) authentication and Cisco AnyConnect.
The root of the problem lies in the new feature implemented in Chromium Version 124, namely the support for TLS 1.3 hybridized with Kyber, which unfortunately disrupts the TLSv1.2 Handshake process. This issue primarily impacts users of Chrome and Edge browsers, where the error displayed is ERR_SSL_PROTOCOL. It is important to note that browsers not based on Chromium, such as Firefox and Safari, remain unaffected.
To resolve this issue for Chrome and Edge users, you can disable the TLS 1.3 hybridized Kyber support by following these steps:
Navigate to the browser's experimental features page:
For Edge: edge://flags/#enable-tls13-kyber
For Chrome: chrome://flags/#enable-tls13-kyber
Set the feature to 'Disabled.'
After making this change, the connection issues with the browser should be resolved.
However, if the problem persists with AnyConnect connections, this may be due to the fact that AnyConnect uses Webview2 Runtime, which does not recognize the flag adjustments made previously. To address this, you will need to create a specific registry value via PowerShell as an Administrator:
For AnyConnect with VPN 4.x:
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Cisco\Cisco AnyConnect Secure Mobility" /v UseLegacyEmbeddedBrowser /t REG_DWORD /d 1 /f
For Cisco Secure Client with VPN 5.x:
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Cisco\Cisco Secure Client" /v UseLegacyEmbeddedBrowser /t REG_DWORD /d 1 /f
This action instructs AnyConnect to utilize the Legacy Browser (Internet Explorer) in place of Edge, which should restore your connection.
We are aware that the update to Chromium-based browsers has been intended to introduce stronger security via TLS 1.3 post-quantum cryptography. However, making TLS1.3 Hybridized Kyber support the default has inadvertently caused disruptions in browser-client interactions.
As an alternative, some users are opting to manually downgrade Webview2 or revert to using the legacy browser. It is also possible to download an earlier version of Webview2 for use with the embedded browser should that be necessary.
05-15-2024 04:30 AM
I was having same problem but only for the traffic which was passing through ipsec tunnel to fix that i reduced firewall interface MTU to 1376 as a adjusted mss
08-15-2024 10:18 PM
Will there be a fixed version for FTD too? In the bug (CSCwj82736) details there are only asa releases listed?
08-18-2024 06:09 AM
There is this bug fixed in 7.4.2: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwj85333
Might be the same issue (Kyber).
08-29-2024 01:29 AM
The recommended release is 7.2.8. Will this bug also be fixed in the 7.2 releases or is it planned to change the recommendation to 7.4.x?
09-03-2024 05:44 AM
Any update on this? I upgraded to 7.4.2 last week, still experiencing the issue. Have not upgrade to SNORT 3 yet, TLSID is disabled. Changing Chrome settings is not a viable option for random users that have this issue. Cisco recommended against Prefilter rules due to security reasons.
09-17-2024 11:05 AM
Example:
1500 = standard MTU
- 20 = IP Header
- 24 = GRE encap
- 52 = IPSec encap
- 8 = PPoE encap (you might not have this one)
- 20 = TCP Header
_________
1376 = Adjusted MSS
configure firewall interface to 1376 MTU it may fix your issue until bug is fixed
09-17-2024 11:14 AM
Could adjusting the MTU to 1376 cause any potential issues?
12-12-2024 11:55 AM
no all was working good
03-25-2025 10:19 AM
I just ran across this discussion. It seems related to my clients issue. The topic, and all the bugs are discussing fragmented client hellos related to the above mentioned browsers.
What we have is a dropped server hello packet. The packets are not out of order. The packets are not IP-fragments but they are spread across 2 tcp packets. The MSS from the server is 1250. The client hello is spread over two packets, one 1250, the other 505. A packet capture on the FTD running 7.2.5-4 shows these two packets traverse the FTD and are sent to the website. It is the server hello which comes back TCP length 1186, and gets dropped. The actual hello is of length 1210. The client only receives the 2nd packet of the two and thus aborts the exchange.
Using packet capture with the trace option, the dropped packet produces this output.
Phase: 6
Type: SNORT
Subtype: firewall
Result: DROP
Elapsed time: 43586 ns
Config:
Network 0, Inspection 0, Detection 0, Rule ID 268435457
Additional Information:
Starting rule matching, zone 4 -> 1, geo 0 -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, user 9999997, urls app.wdesk.com, hosts app.wdesk.com, no xff
Matched rule ids 268435457 - Allow
Result:
input-interface: outside(vrfid:0)
input-status: up
input-line-status: up
Action: drop
Time Taken: 389441 ns
Drop-reason: (none) Not a blocking packet, Drop-location: frame 0x0000558ca558c1cc flow (NA)/NA
So far TAC has not been helpful, and the related bugs were not mentioned.
Client has tested with browsers TLS13-kyber disabled as mentioned above and was successful in connecting to the website.
Website is app.wdesk.com in case anyone wants to test it.
Firefox does not seem to create this issue.
03-25-2025 11:55 AM
03-25-2025 02:45 PM
Thanks for the feedback Jon. I see two things wrong with pre-filter rule. If as suggested to pre-filter https, then catagory filtering cannot be done. If being managed by FDM, as I understand, no prefiltering built into the GUI.
03-26-2025 03:15 AM
03-26-2025 10:00 AM
I had issues with certain sites dropping https traffic for about a year. Finally version 7.4.2.1 (build 30) fixed my issue.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide