当サイトはユーザー体験を改善するためのメンテナンスを実施中に機能が制限される予定です。記事を読んでもあなたの問題が解決せず質問をしたい場合は、Twitter の @FirefoxSupport、Reddit の /r/firefox で、サポートコミュニティが皆さんを助けようと待機しています。

Mozilla サポートの検索

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.

詳しく学ぶ

このスレッドはアーカイブに保管されました。 必要であれば新たに質問してください。

PR_CONNECT_RESET_ERROR on our website

  • 12 件の返信
  • 3 人がこの問題に困っています
  • 1 回表示
  • 最後の返信者: 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).

この回答をすべて読む 👍 0

すべての返信 (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.

この投稿は 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).

この投稿は 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.