Closed Bug 1839337 Opened 11 months ago Closed 6 months ago

Persistent PR_CONNECT_RESET_ERROR on science.gov

Categories

(Web Compatibility :: Site Reports, defect)

defect

Tracking

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

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

People

(Reporter: denschub, Unassigned)

References

(Blocks 1 open bug, Regression, )

Details

(Keywords: regression, webcompat:site-wait)

Attachments

(1 file)

Trying to access https://www.science.gov 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 science.gov 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 science.gov 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.

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

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

Status: RESOLVED → REOPENED
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.

Osti.gov is now fixed by the site operator. Science.gov remains broken in Firefox and Chrome.

Science.gov have now fixed their incompatibility and use TLS 1.3

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

Attachment

General

Created:
Updated:
Size: