PR_CONNECT_RESET_ERROR on our website
Few days ago, some of our clients and few (not all) internal PC are get stucked on a PR_CONNECT_RESET_ERROR on our website. Only on 117 windows version (118 developer version and 119 nightly seems ok). We tried to repair firefox, it works on 95% but we can't ask our client to do this. It works on Chrome & Edge.
We running out of ideas : - we only accept TLS 1.2 / 1.3 - checking CSP - Both IIS and Apache are not working - Firewall are not blocking
Izabrano rješenje
In the end it was our firewall rules blocking the ECH (the hand shake part).
The "randomness" was the ECH flag enabled or not on differents PC of the company. network.dns.echconfig.enabled or security.tls.ech.grease_probability were not the same on all the PC (strange because no one changed it, and everyone was on 117 release).
Pročitajte ovaj odgovor sa objašnjenjem 👍 0All Replies (12)
Add: The "repair" works but if I close firefox and re-open I get the error.
It could be, but we can't ask all our client to disconnect Kaspersky. And we have the error on PCs without Kaspersky (but F-Secure).
The website.
Izmjenjeno od strane zakwil
It could be, but we can't ask all our client to disconnect Kaspersky. And we have the error on PCs without Kaspersky (but F-Secure).
The website.
This is due to Firefox having ECH enabled, Chrome produces the same result with the "Encrypted ClientHello" flag enabled.
Bug 1839337 and Bug 1847804 detail similar site breakages:
The TLS load balancer at <WEBSITE> 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 <WEBSITE> failing.
@zeroknight Thanks we going to check that and test our load balancer.
It seems Firefox tries to connect on TLS1.3 but stops the connexion
If we force firefox config only to TLS 1.2 it works (we can't ask that to our clients...). Something with Encrypted ClientHello and TLS 1.3 ?
Log 2023-09-21 12:26:34.963000 UTC - [Parent 23092: Socket Thread]: D/nsSocketTransport PR_Write returned [n=-1] 2023-09-21 12:26:34.963000 UTC - [Parent 23092: Socket Thread]: D/nsSocketTransport ErrorAccordingToNSPR [in=-5961 out=804b0014]
The problem lead to ECH (Encrypted Client Hello). But we don't know how to properly avoid it.
The site is accessible currently with ECH enabled.
Odabrano rješenje
In the end it was our firewall rules blocking the ECH (the hand shake part).
The "randomness" was the ECH flag enabled or not on differents PC of the company. network.dns.echconfig.enabled or security.tls.ech.grease_probability were not the same on all the PC (strange because no one changed it, and everyone was on 117 release).
Izmjenjeno od strane zakwil
ECH is currently in a limited rollout. You can see rollouts in about:support#remote-features and in version 119 they will also be listed in about:studies.