1943471 - Firefox negotiates mlkem in TLS for initial request, but not in later requests, but for only some websites

Status: RESOLVED DUPLICATE of bug 1941041

(Core :: Networking, defect, P2)

Description

[Andrew Scott]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

Using the Quantum Safety browser extension (https://addons.mozilla.org/en-US/firefox/addon/quantum-safety/) to show what key exchange algorithm was negotiated by Firefox in the current TLS session (via webRequest.SecurityInfo.keaGroupName), I visited particular websites. These showed a green tick in the browser extension initially, and mlkem768x25519 was reported to be used as the algorithm. When the reload button was pressed, the green tick disappeared and x25519 was reported as the algorithm used. Closing the tab or browser window, and returning to the website again showed x25519 was being used. However, completely restarting Firefox had the green tick reappear and mlkem768x25519 was reported. However, certain other websites show the green tick and report mlkem768x25519 always, even after reloading the page.
It appears that Firefox negotiates the use of mlkem768x25519 as the key exchange algorithm for initial requests on some websites, but then negotiates x25519 for later requests on those websites. However, on other websites, it sticks with mlkem768x25519.
The security implication of this is that the user or website owner might think that they are protected with post quantum cryptography when using Firefox on those websites, but it is only with the initial request that they are protected, and they are not actually protected on later page requests. Hence they will be vulnerable to store now decrypt later attacks that algorithms like mlkem768x25519 should have protected them from.

Actual results:

Visiting these websites displayed the problem:

• www.cloudflare.com
• www.google.com
• blog.mozzila.org

For these, the initial request had a green tick / reported mlkem768x25519 being used, but later requests or reloading of the web page resulted in the green tick disappearing, and Firefox reporting it was used just x25519.

Restarting the Firefox browser reset the behaviour, but simply closing the browser tab or window did not.

However, visiting these websites doesn't show the problem:

• stackoverflow.com
• zoom.com
• gsma.com

These show a green tick, and report mlkem768x25519 being used, even if the page is reloaded multiple times.

Expected results:

Whenever a website that uses post quantum cryptography is visited, it should show a green tick in the browser extension and report an algorithm like mlkem768x25519 being used, even if the page is reloaded. In other words, the websites in the first set should behave in Firefox like the websites in the second set.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Andrew Scott]

Attachment: Screenshot of Browser Console showing reports from Quantum Safety add-on

This screenshot of the Browser Console show reports from the Quantum Safety add-on, highlighting that the key exchange algorithm changes for www.cloudflare.com when the page is reloaded, but not for stackoverflow.com when it is reloaded.

Comment 3

[Andrew Scott]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #1)

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

The bug isn't related to web browser extensions. A web browser extension is simply used to show what is happening under the hood with Firefox.

Comment 4

[Andrew Scott]

I've done further investigation using Wireshark to look at differences in traffic between Firefox and those various sites. The ones where the problem appears seem to make use of QUIC, while the ones without the problem seem to be using HTTP over TLS. Additionally, looking at the key exchange algorithms offered in the QUIC Initial packet (which includes a TLS Client Hello) sent by Firefox, mlkem768x25519 is not listed. As a result, I went into about:config and changed network.http.http3.enable to false. After I did this, the problem stopped, which seems to confirm that it is something to do with how QUIC is implemented in Firefox, and that perhaps support for mlkem768x25519 is missing or incomplete.

Comment 5

[Manuel Bucher [:manuel]]

The ones where the problem appears seem to make use of QUIC

I'm going to move this to Core :: Networking based on this investigation. @new triage owner: Feel free to forward to Core :: Security: PSM if the integration is more on the NSS side.

Comment 6

[Lars Eggert [:lars]]

It's probably because of this: https://github.com/mozilla/neqo/blob/7315d103bdbc604084826fab7f31a333c5ff51f5/neqo-transport/src/crypto.rs#L82-L100

Comment 7

[Kershaw Chang [:kershaw]]

See https://github.com/mozilla/neqo/pull/2389.

Comment 8

[John Schanck [:jschanck]]

ML-KEM is enabled by default in h3 in Firefox 135+ (Bug 1941041). You can enable it in 134 by setting network.http.http3.enable_kyber to true.

Comment 9

[Andrew Scott]

Thanks. Great to know this is fixed in v135.