ابحث في الدعم

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

PR_CONNECT_RESET_ERROR on our website

  • 12 ردًا
  • 3 have this problem
  • 1 view
  • آخر ردّ كتبه zeroknight

more options

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

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

الحل المُختار

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).

Read this answer in context 👍 0

All Replies (12)

more options

Add: The "repair" works but if I close firefox and re-open I get the error.

more options
more options

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.

Modified by zakwil

more options

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.

more options

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.
more options

@zeroknight Thanks we going to check that and test our load balancer.

more options

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]

more options

The problem lead to ECH (Encrypted Client Hello). But we don't know how to properly avoid it.

more options
more options

The site is accessible currently with ECH enabled.

more options

الحل المُختار

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).

Modified by zakwil

more options

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.