Description
This article describes a known issue related to ML-KEM post-quantum TLS key exchange, which has recently become supported in the following browser versions:
- Google Chrome 131.
- Microsoft Edge 131.0.2903.48 (Stable).
- Mozilla Firefox 132.0.
This issue has been observed to occur when using Flow-based TLS Deep Inspection on the FortiGate along with the web browser versions mentioned above (including later versions). Proxy-based TLS Deep Inspection is not affected.
Scope
FortiGate.
Solution
When this issue occurs, users will find that certain websites will fail to load and will present an ERR_SSL_PROTOCOL_ERROR error message.
This issue is triggered by the addition of ML-KEM post-quantum TLS key exchange, which recently replaced X25519Kyber768 for hybrid post-quantum key exchange on Chrome-based browsers: A new path for Kyber on the web.
Some example websites that have been found to demonstrate the issue while using Google Chrome include:
Some websites like the Azure portal or the Microsoft SSO login page (login.microsoftonline.com) will not show this error. For example, the Azure portal will simply show the message 'Portal offline', whereas the Microsoft SSO login page will show a blank page.
For precise identification, obtain a packet capture of the relevant traffic and inspect the packets in Wireshark.
A ClientHello message generated by an application using ML-KEM will show it being offered, as shown in the following example:
'Extension: supported_groups' and 'Extension: key_share' will contain group ID 0x11ec (hexadecimal) or 4588 (the same value in decimal notation).
Additionally, the packet capture will show a fatal TLS alert with description 'Illegal Parameter' as follows:
Note:
Future Wireshark versions may show the proper name of the ML-KEM group, once support is implemented. As of version 4.4.2, it is not implemented.
If these group IDs are found in the ClientHello then issues with flow-mode inspection are expected to happen. Use the following command to check the current version of IPS Engine running on the FortiGate, then compare against the list in the Long-Term Resolution section to see which version has resolved this issue:
diagnose autoupdate versions | grep 'Attack Engine' -A 7
Workarounds:
Any one of the following workarounds can be effective as a temporary solution to the issue:
- On the FortiGate:
- Switch Firewall Policies from using Flow-Based + Deep Inspection to one of the following options:
- Proxy-Based + Deep Inspection.
- Flow-based +Certificate Inspection.
- Proxy-based + Certification Inspection.
- Alternatively, add an SSL Exemption for the affected website in a custom SSL Deep Inspection profile (see also: Technical Tip: Exempting applications/domains/websites from SSL Inspection).
- Switch Firewall Policies from using Flow-Based + Deep Inspection to one of the following options:
- In Google Chrome:
- Disable ML-KEM support OR disable PostQuantumKeyAgreementEnabled.
- Disabling ML-KEM is possible on a per-browser basis by going to chrome://flags and disabling Use ML-KEM in TLS 1.3 (#use-ml-kem).
- Disabling PostQuantumKeyAgreementEnabled is possible via Chrome Enterprise Policy or Windows Group. Policy: PostQuantumKeyAgreementEnabled.
- Note: The PostQuantumKeyAgreementEnabled Enterprise Policy is specified by Google to be a temporary measure, so it will only be available 'through the end of 2024' (Update Google Play Services to fix issues with on-device passwords for more information).
- While this is not a long-term solution, this is a valid workaround for addressing website access issues for Chrome users today who are using Flow-based TLS Deep Inspection on the FortiGate.
- In Microsoft Edge:
Disable the flag called 'TLS 1.3 post-quantum key agreement' in edge://flags.
Long-Term Resolution (as of 12/02/2024):
The problem is under active investigation as part of Known Issue #1097642. Fixes are being assessed as part of new IPS Engine builds for v7.0, v7.2, v7.4, and v7.6 at this time. According to development, the issue has been fixed starting with the following IPS Engine versions:
- v7.0 IPSE 7.0189.
- No additional information at this time. Can be updated manually, or use a newer firmware version.
- v7.2 IPSE 7.0353 (FortiOS 7.2.11 comes with newer ipsengine 7.0357)
- Note that IPSE 7.0353 is scheduled for a phased rollout via FortiGuard Distribution Network starting from November 19th, 2024, which means that FortiGates running FortiOS v7.2.0 and later v7.2 patch releases will automatically receive this IPS Engine build throughout November (refer to CSB-241115-1 on the Fortinet Support site for further information).
- v7.4 IPSE 7.0555 (FortiOS 7.4.6 comes with newer ipsengine 7.0559)
- FortiOS 7.4.6 has been made available for download as of December 13th, 2024, and it includes IPS Engine 7.0559 as the built-in version (which resolves this ML-KEM issue). Upgrading to FortiOS 7.4.6 is now an available option for resolving this issue.
- v7.6 IPSE 7.1026 (default engine in FortiOS 7.6.1)
- FortiOS v7.6.1 has been made available for download as of November 28th, 2024, and it includes IPS Engine 7.1026 as the built-in version (which resolves this ML-KEM issue). Upgrading to FortiOS 7.6.1 is now an available option for resolving this issue.
The following KB article can be used to perform a manual IPS Engine upgrade: Technical Tip: How to manually upgrade the IPS Engine.
Note:
The FortiGate will only auto-update the IPS Engine via FortiGuard if the flow-based inspection is being actively utilized. To satisfy this requirement, there must be at least one of the following configured on the FortiGate:
- A Firewall Policy set to Flow-based Inspection with any security inspection applied (Web Filter, DNS Filter, AV, etc.,) or:
- A Firewall Policy that has IPS enabled, or:
- A Firewall Policy that has Application Control enabled.
This ML-KEM issue specifically affects users with Flow-based Firewall Policies using SSL/TLS Deep Inspection enabled, so this requirement should already be satisfied for affected FortiGates.
Related articles:
