Tìm kiếm hỗ trợ

Tránh các lừa đảo về hỗ trợ. Chúng tôi sẽ không bao giờ yêu cầu bạn gọi hoặc nhắn tin đến số điện thoại hoặc chia sẻ thông tin cá nhân. Vui lòng báo cáo hoạt động đáng ngờ bằng cách sử dụng tùy chọn "Báo cáo lạm dụng".

Tìm hiểu thêm

PR_CONNECT_RESET_ERROR on our website

  • 12 trả lời
  • 3 gặp vấn đề này
  • 1 lượt xem
  • Trả lời mới nhất được viết bởi 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

Giải pháp được chọn

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

Đọc câu trả lời này trong ngữ cảnh 👍 0

Tất cả các câu trả lời (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.

Được chỉnh sửa bởi zakwil vào

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

Giải pháp được chọn

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

Được chỉnh sửa bởi zakwil vào

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.