cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
34390
Views
17
Helpful
43
Replies

FTD's - Firepower dropping HTTPS traffic using TLS 1.3 Hybridized Kybe

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.

 

 

Please rate as helpful, if that would be the case. Thanx
43 Replies 43

rpinasar
Cisco Employee
Cisco Employee

TLS 1.3 Hybridized Kyber Support Issue Affecting Browser Connections.

 

rpinasar_0-1715279755623.png

 

 

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.

 

 

srajiwate
Level 1
Level 1

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 

-Tobi-
Level 1
Level 1

Will there be a fixed version for FTD too? In the bug (CSCwj82736) details there are only asa releases listed? 

There is this bug fixed in 7.4.2: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwj85333

Might be the same issue (Kyber). 

-Tobi-
Level 1
Level 1

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?

cslack1313
Level 1
Level 1

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. 

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 

 

Could adjusting the MTU to 1376 cause any potential issues? 

no all was working good 

Garry Cross
Level 1
Level 1

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.

 

We are using OS policies to avoid this issue, running 7.4.2 on all FTD's now. Will use that test website tomorrow and check. Dont think this is fixed yet, not even in 7.6.0, but will check this also. TAC was no help either, suggestion was to prefilter all https traffic.
Please rate as helpful, if that would be the case. Thanx

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.

Always used FMC to manage FTD's which can deploy prefilter rules. Are you saying that in FDM this is not possible ?
Please rate as helpful, if that would be the case. Thanx

I had issues with certain sites dropping https traffic for about a year. Finally version 7.4.2.1 (build 30) fixed my issue. 

Review Cisco Networking for a $25 gift card