Problems with Enterprise firewalls and TLS-inspection using Firefox 140esr or Firefox 143

[Kahle, Markus]

Hi,

we are currently running into problems switching from FF128esr to FF140esr (or even to FF143):

Using FF128esr (128.14.0) everything is mostly behaving normal in case of loading webpages.

But when switching to FF140esr, with changing no other variables, we have massive problems loading websites.

e.g. opening www.google.de with active redirect www.google.com :

Loading time FF128esr:  2-4 seconds

Loading time FF140esr:  ranging from 15-50 seconds ( behavior is reproducible )

This problem is not limited to www.google.de with broad impact on various websites, we just used www.google.de for testing.

Once the website is loaded completely, next visit of the page gets normal loading times ( some kind of "caching" in FF ?)

But right after a complete restart of FF140esr its back to the long loading times.

After doing some research and testing, we can bring FF140esr back to normal by disabling TLS inspection on our firewall ( SFOS ).

Because we haven't got the problem with FF128esr and haven't changed anything on firewall side, it has to be a problem of FF140esr.

Has anyone similar problems with FF140esr and TLS-inspection firewalls ?

Anything we do about it ? Switching off TLS inspection is no option globally! We only want to stay on FF128esr as long as it's necessary.

Markus

[Benjamin Beurdouche]

Hi, 

In about:config can you try to set `security.tls.enable_kyber` to false and see if it solves the issue ?

Thanks !

B.

--
You received this message because you are subscribed to the Google Groups "enter...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise+...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/865924046.2252193.1758289454614.JavaMail.zimbra%40brueckmann-gmbh.de.

[Kasper, Ryan V. [US-US]]

We saw similar and setting network.http.http3.enable=false was my workaround – related bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1980812

 

Thank you,

Ryan V. Kasper

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/0988F31E-8BC5-4F5B-9066-E3A4C7048AEC%40mozilla.com.

[Kahle, Markus]

Hi Ryan,

I can confirm that switching that option to 'false' instantly solve the problem.

The loading time seems even better than with FF128ESR, www.google.com via www.google.de comes up instantanious, same with www.deepl.com (another website with long loading times).

Switching it back to 'true' (without quitting browser) also restores the error.

@Mozilla: Is there any date for resolving the bug ? What is the impact in using the config option as a workaround till then ?

Thanks,

Markus

---

[Chris Puttick]

I'd hazard a guess the browser is trying a connection on http3 and falling back to http2 because the firewall is in the way. Without knowing anything about the capabilities of the installed firewall, it's likely it cannot or isn't set up to handle TLS intercepts on http3

---

From: "Kahle, Markus" <markus...@brueckmann-gmbh.de>
To: "enterprise" <enter...@mozilla.org>
Sent: Monday, 22 September, 2025 07:54:29
Subject: Re: [Mozilla Enterprise] Problems with Enterprise firewalls and TLS-inspection using Firefox 140esr or Firefox 143

--
You received this message because you are subscribed to the Google Groups "enter...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise+...@mozilla.org.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/2068799935.2349782.1758524069501.JavaMail.zimbra%40brueckmann-gmbh.de.

[Gruhm, Sebastian]

Hello Benjamin,

 

I changed “security.tls.enable_kyber” to false reopened Firefox an it works. Thanks a lot!

 

I think at the moment we are still safe with this setting on false but what should I do to reenable this setting? Or is it a bug which Mozilla has to fix and there is nothing I can/have to do on my site?

 

Mit freundlichem Gruß

 

Sebastian Gruhm

 

Freie Universität Berlin
Zentraleinrichtung FUB-IT
Abteilung Infrastruktur

Bereich Server

Fabeckstraße 32, 14195 Berlin
Raum: 110
Telefon: +49 30 838 58668
E-Mail: sebasti...@fu-berlin.de
Internet: www.it.fu-berlin.de

 

Von: Benjamin Beurdouche <bbeur...@mozilla.com>
Gesendet: Freitag, 19. September 2025 17:12
An: Kahle, Markus <markus...@brueckmann-gmbh.de>; rigo...@gmail.com; Gruhm, Sebastian <Sebasti...@fu-berlin.de>
Cc: Mozilla.org <enter...@mozilla.org>
Betreff: Re: [Mozilla Enterprise] Problems with Enterprise firewalls and TLS-inspection using Firefox 140esr or Firefox 143

 

Hi, 

[Gruhm, Sebastian]

Hello Ryan,

 

setting network.http.http3.enable=false did not help.“security.tls.enable_kyber” did the trick.

 

Mit freundlichem Gruß

 

Sebastian

 

Von: Kasper, Ryan V. [US-US] <Ryan.V...@leidos.com>

Gesendet: Freitag, 19. September 2025 17:23
An: Benjamin Beurdouche <bbeur...@mozilla.com>; Kahle, Markus <markus...@brueckmann-gmbh.de>; rigo...@gmail.com; Gruhm, Sebastian <Sebasti...@fu-berlin.de>
Cc: Mozilla.org <enter...@mozilla.org>

[Kahle, Markus]

Hi,

I was doing some more research on this http3 option and I'm far from being a network/http3/quic procotol expert, but maybe my problem has something to do with this http3/quic protocol itself.

As we are doing TLS inspection and this probably has issues with http3/quic TLS 1.3 over UDP.  It seems to be recommended to use only http2 TCP Connections with TLS1.2 for TLS Inspection to properly work.

There is even an option in our firewall to block quic protocol from going through the firewall ( which is by default enabled ). Maybe this also adds to the problem of long loading times with http3 in firefox 140esr.

Strangly chromium based browsers haven't got the problem at all, no need to disable http3/quic or any options in the firewall.

So for us it should be better to switch off http3 in our browser anyway.

Maybe I will test again with this security.tls.enable_kyber option, if this is also fixing our problem.

Is there an offical position from Mozilla regrading this http3/quic procotol in case of enterprise tls inspection ?

Thanks,

Markus

---

[Gruhm, Sebastian]

After some more testing it stopped working again. For further testing, I went back to Version 128 ESR to create an “new” V128 profile than reinstalled 140.3.0 ESR but wasn’t able to reproduce the error. I am confused… 😊

 

I told my 1^st-LVL to just create a new profile where Firefox 140 ESR doesn’t work and will call it a day.

 

Mit freundlichem Gruß

 

Sebastian

 

 

Von: enter...@mozilla.org <enter...@mozilla.org> Im Auftrag von Gruhm, Sebastian

Gesendet: Montag, 22. September 2025 10:57
An: Benjamin Beurdouche <bbeur...@mozilla.com>; Kahle, Markus <markus...@brueckmann-gmbh.de>; rigo...@gmail.com

Cc: Mozilla.org <enter...@mozilla.org>
Betreff: AW: [Mozilla Enterprise] Problems with Enterprise firewalls and TLS-inspection using Firefox 140esr or Firefox 143

 

Hello Benjamin,

 

I changed “security.tls.enable_kyber” to false reopened Firefox an it works. Thanks a lot!

 

I think at the moment we are still safe with this setting on false but what should I do to reenable this setting? Or is it a bug which Mozilla has to fix and there is nothing I can/have to do on my site?

 

Mit freundlichem Gruß

 

 

Von: Benjamin Beurdouche <bbeur...@mozilla.com>

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/1ca63ba98ac74e11b088f0c5ed318780%40fu-berlin.de.

[Romain Testard]

Sebastian and Markus, we're actively looking into a fix but understanding better your proxy set-up would help a lot. Would you mind sharing details on your proxy configs so we can make sure that the fix works reliably? 

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/7f7f87a699f54b478bbc383ff1a922cc%40fu-berlin.de.

[Benjamin Beurdouche]

Hi Sebastian, Hi Markus,

Dear all,

We are actively looking into it. @Sebastian, thanks for checking the kyber pref.

Let’s assume that kyber is not involved for now, and that the underlying issue is H3.

There is a good description of what we think might be happening here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1980812#c12

For Markus’ question about TLS inspection, we disable HTTP/3 when detecting a third party root certificate on a new connection. 

More details in https://bugzilla.mozilla.org/show_bug.cgi?id=1985341#c7

-- Important --

Below you can find an ESR build that contains the fix for that problem (1980812).

Could you both please check if the following build solves the issue ?

Please also see Romain’s email about your setup, so that we understand more... : )

MacOS

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Hs1RC3kuRsWMZb46ynGAgg/runs/0/artifacts/public/build/target.dmg

Linux

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Q74awoWxSmGolsUamLGq9g/runs/0/artifacts/public/build/target.tar.xz

Windows

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/DAijbDUoSJ-Xlse0T3lb0A/runs/0/artifacts/public/build/target.zip

(Full, CI run)

https://treeherder.mozilla.org/jobs?repo=try&revision=d39ba26b11509057b25da662dbb7690b1ff618f2

Many thanks ! : )

Benjamin & al.

[Ruben Gomez]

Thanks I’ll give it a go 

Sent from my iPhone

On Sep 22, 2025, at 7:36 AM, Benjamin Beurdouche <bbeur...@mozilla.com> wrote:



<signature.asc>

[Kahle, Markus]

Hi there,

I have done a little very non-scientific test series with firefox 140esr and your nightly version.

Both with ether http3 enabled or disabled using www.google.de (with the redirect to www.google.com) as a reproducible source of the error.

In all attempts I used the "refresh Firefox" function to get some kind of baseline. All 4 variants I tried 5 times.

Here is my list testing www.google.de:

Browser	with http3 enabled	with http3 disabled
Firefox 140ESR	30sec	3sec
	41sec	3sec
	31sec	2sec
	58sec	2sec
	48sec	2sec
Nightly 140ESR	2sec	2sec
	4sec	2sec
	4sec	2sec
	3sec	2sec
	3sec	2sec

It seems that the fix in the posted nightly some kind helped solving the problem. It's still not as consistent as the one with http3 disabled, but I'm also far from consistent test conditions.

I case of our setup: We are using a Sophos Firewall with SFOS 21.5 and transparent proxy with TLS inspection. As alread mentioned the "block QUIC protocol" option is set by default.

Markus

---

[Benjamin Beurdouche]

Hi Markus, hi all,

Thanks a lot for the report. This matches our expectations. 

Because the firewall is set to block QUIC, there is an additional network round trip to downgrade from H3 to H2 which is why the performance is degraded. If you don’t have specific reasons to prevent using QUIC, I would recommend simply disabling that block to get the highest performance.

With respect to the release, we have prepared a dot release of ESR that is being tested by QA as we speak, so hopefully everyone will have that release available today… :)

Best,

Benjamin

On Sep 23, 2025, at 1:06 PM, Kahle, Markus <markus...@brueckmann-gmbh.de> wrote:



To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/enterprise/68386194.2639642.1758625589773.JavaMail.zimbra%40brueckmann-gmbh.de.

[Benjamin Beurdouche]

Dear all,

Following Donal announcement, I confirm that ESR 140.3.1 is 100% rolled out and ready to use.

Many thanks to you Markus, Sebastian and Ruben for the reports and the follow-up discussion.

Please don’t hesitate to follow-up if you have any issue.

Best,
Benjamin for the Firefox team

[Benjamin Beurdouche]

Ps: The fix is already in Fx 144 beta and will be uplifted to a Fx 143 dot release next week.