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
Seçilen çözüm
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).
Bu yanıtı konu içinde okuyun 👍 0Tüm Yanıtlar (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.
zakwil tarafından tarihinde düzenlendi
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.
Seçilen çözüm
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).
zakwil tarafından tarihinde düzenlendi
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.