1839337 - Persistent PR_CONNECT_RESET_ERROR on science.gov

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Dennis Schubert [:denschub]]

Attachment: log.txt-main.49059.moz_log.gz

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.

Comment 1

[Dennis Schubert [:denschub]]

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

Can you take a look, Dennis?

Comment 2

[Dennis Schubert [:denschub]]

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

Comment 4

[Dennis Jackson]

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.

Comment 5

[Dennis Schubert [:denschub]]

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

Comment 6

[Dianna Smith [:diannaS]]

:djackson any update from your end?

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

Comment 7

[Dennis Schubert [:denschub]]

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

Comment 8

[Dennis Jackson]

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.

Comment 9

[Dennis Jackson]

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

[Dennis Jackson]

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

Comment 11

[Dennis Jackson]

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