Firefox Community Forum

Hello,

I have been testing all browsers I use (Firefox, Chrome, Edge) on Cloudflare Post-Quantum Key Agreement to verify PQC support. They all support the X25519MLKEM768 hybrid scheme (i.e. Cloudflare web page returns "You are using X25519MLKEM768 which is post-quantum secure").

The issue: When I run the test in Firefox multiple times by doing repeated hard refreshes (Ctrl+Shift+R), quite often the result is "You are using X25519 which is not post-quantum secure". Sometimes the very first run after opening Firefox gives the X25519 (failing) result. "Often" varies. Sometimes it's around 10 fails out of 50 tests, other times it's 1 out of 50. It seems random.

I have read that sometimes networking equipment or even ISPs can be the cause of PQC requests falling back to non-PQC due to the long keys in PQC, but I do not see this intermittent issue with Chrome or Edge on the same computer/network/ISP as Firefox. I have not seen a single failure so far on those two browsers. The only variable I am aware of is the web browser.

I also tried connecting to a cellular hotspot as well as disabling my Norton 360 firewall and the results are the same as above.

Looking for help to resolve this issue. Thanks.

Hi guys, Had Firefox as network default browser for decades. Now I have a problem with my DNS pihole filter, firefox just goes around it. I've read countless articles on how to stop this, I've tried DoH 0 and DoH 5, I've placed a file policies.json in a distribution folder. I've tied everything I can find on the net. Nothing and I do mean nothing, had the slightest effect. Firefox goes around whatever I try.

I've spent many, many hours on this please tell me how to kill this, I'm forced to use another browser at the moment, which is painful.

version 142.0.1 64bit W11.

Thank you Bob.

Hello community, I'm an embedded systems developer and we have a ressource constraint IOT device which is using TLS1.2. When we use https:// to access the internal website of the device, Firefox does a complete TLS handshake for each asset to download which renders https:// almost unusable. This happens despite session resumption using session IDs is offered by the device. When accessing the device with Chrome or Edge there's only one handshake and all the following TLS sessions are resumed with the ID of the first handshake. In Firefox security.ssl.disable_session_identifiers is set to false.

Is it intended behaviour that Firefox ignores session IDs for TLS1.2?

Used Firefox version: 142.0 (64-Bit) Windows 11

Thanks in advance.

Johannes

I wanted to completely disable TLS 1.3 when using Firefox, so I set security.tls.version.max to 3 (which corresponds to TLS 1.2). That worked up until I got version 140.0.4 installed - now it completely ignores this setting no matter what I set. I tried using cloudflare-ech.com website for test and it confirms that my browser uses TLS 1.3 with ECH. I also tried modifying security.tls.version.fallback-limit to 0 and security.tls.version.min to 0 to get a possible range of TLS 1.0-1.2, but it still uses TLS 1.3.