Closed Bug 1839337 Opened 11 months ago Closed 6 months ago



(Web Compatibility :: Site Reports, defect)



(firefox-esr102 unaffected, firefox114 disabled, firefox115 disabled, firefox116 disabled, firefox117 disabled)

Tracking Status
firefox-esr102 --- unaffected
firefox114 --- disabled
firefox115 --- disabled
firefox116 --- disabled
firefox117 --- disabled


(Reporter: denschub, Unassigned)


(Blocks 1 open bug, Regression, )


(Keywords: regression, webcompat:site-wait)


(1 file)

Trying to access results in a persistent PR_CONNECT_RESET_ERROR, while it works fine in Chrome and Safari.

I've attached a (gzipped) networking log if that helps.

According to mozregression, this is bug 1824578 - which is Nightly-only.

Can you take a look, Dennis?

Flags: needinfo?(djackson)
Keywords: regression
Regressed by: 1824578

(setting the release tracking flag before the bot has a chance to.)

Flags: needinfo?(smayya)

I've investigated the situation. The TLS load balancer at is configured incorrectly and rejects client connections containing any TLS extension it doesn't recognise. There's nothing specific to bug 1824578, it just happens to be the first new TLS extension in a little while. Testing on Chrome Canary with same flag enabled also leads to connections with failing.

As this failure is due to the server incorrectly implementing TLS1.3 and the failure is going to occur on all modern web browsers, there isn't much we can do here. I'll reach out to the web admin listed on their contact us page to see if they'll correct their configuration.

Closed: 11 months ago
Flags: needinfo?(djackson)
Resolution: --- → WONTFIX

Let us know if you can't get someone to respond.

Component: Networking → Desktop
Product: Core → Web Compatibility
Resolution: WONTFIX → ---

:djackson any update from your end?

:denschub is there anything we can disable in nightly to prevent this or any action in the meantime ?

Flags: needinfo?(dschubert)
Flags: needinfo?(djackson)

I haven't even gotten as much as an acknowledgement, unfortunately.

Flags: needinfo?(dschubert)

I reached out the web admin and received an acknowledgment indicating they'd read the email. I tested again today and the site continues to fail to load in Firefox Nightly and Chrome Canary (with the ECH flag enabled). I've emailed the web admin to highlight that this is going cause their site to become unavailable in the near future.

Unfortunately there's not much we can do on our side. This is a faulty server implementation which is going to break with any new TLS feature. We currently ship Nightly with our TLS fallback disabled exactly so that we can detect sites like this prior to going to release. Impacted Nightly users can temporarily set: security.tls.ech.disable_grease_on_fallback to true, but I would strongly prefer to keep the default to false so that we can continue to get user reports of any other faulty sites.

Flags: needinfo?(djackson)
Blocks: ech

I received a message from the web admin stating that they'd deployed TLS 1.3 and asking me to retest. Unfortunately, the issue remains and it seems likely they have some kind of faulty or misconfigured network device in between their TLS servers and the web. Further, although they now support TLS 1.3 as well as TLS 1.2, their server is misconfigured and will always negotiate 1.2 given the choice.

I tested this via SSL Labs, note the handshake simulation results:

and I also confirmed that the site will negotiate TLS 1.3 with Firefox and Chrome, but only if Firefox & Chrome disable TLS 1.2 support.

I've reached out to the web admin with these results. Hopefully they'll be able to fix the issue. is now fixed by the site operator. remains broken in Firefox and Chrome. have now fixed their incompatibility and use TLS 1.3

Closed: 11 months ago6 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.