Persistent PR_CONNECT_RESET_ERROR on science.gov
Categories
(Web Compatibility :: Site Reports, defect)
Tracking
(firefox-esr102 unaffected, firefox114 disabled, firefox115 disabled, firefox116 disabled, firefox117 disabled)
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)
775.32 KB,
application/x-gzip
|
Details |
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.
Reporter | ||
Comment 1•2 years ago
|
||
According to mozregression, this is bug 1824578 - which is Nightly-only.
Can you take a look, Dennis?
Reporter | ||
Comment 2•2 years ago
|
||
(setting the release tracking flag before the bot has a chance to.)
Reporter | ||
Updated•2 years ago
|
Comment 4•2 years ago
|
||
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.
Reporter | ||
Comment 5•2 years ago
|
||
Let us know if you can't get someone to respond.
Comment 6•2 years ago
|
||
:djackson any update from your end?
:denschub is there anything we can disable in nightly to prevent this or any action in the meantime ?
Reporter | ||
Comment 7•2 years ago
|
||
I haven't even gotten as much as an acknowledgement, unfortunately.
Comment 8•2 years ago
|
||
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.
Updated•1 years ago
|
Comment 9•1 year ago
•
|
||
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:
- https://www.ssllabs.com/ssltest/analyze.html?d=science.gov
- https://www.ssllabs.com/ssltest/analyze.html?d=osti.gov
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.
Comment 10•1 year ago
|
||
Osti.gov is now fixed by the site operator. Science.gov remains broken in Firefox and Chrome.
Comment 11•1 year ago
|
||
Science.gov have now fixed their incompatibility and use TLS 1.3
Description
•