PR_CONNECT_RESET_ERROR on ibb.co
Categories
(Core :: Networking, defect)
Tracking
()
People
(Reporter: milindhvijay, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0
Steps to reproduce:
- Opened Firefox Stable (v.126.0).
- Entered the URL https://ibb.co in the address bar and pressed Enter.
- Tried accessing the same URL using Firefox in private browsing mode and with all extensions disabled.
- Cleared cookies and cache, then attempted to access the URL again.
- Restored Firefox settings to default and retried accessing the URL.
Actual results:
Secure Connection Failed
An error occurred during a connection to ibb.co. PR_CONNECT_RESET_ERROR
Expected results:
The URL https://ibb.co should have redirected to https://imgbb.com without any errors, as it does in chromium-based browsers (Chrome and Arc), Safari, and Firefox Nightly (v.128.0a1).
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•2 years ago
|
||
I can't reproduce this locally, so maybe this is fixed at the server side.
Are you still able to reproduce this? If yes, can you try to record a http log and send the log to necko@mozilla.com?
Thanks.
|
Reporter | |
Comment 3•2 years ago
|
||
(In reply to Kershaw Chang [:kershaw] from comment #2)
I can't reproduce this locally, so maybe this is fixed at the server side.
Are you still able to reproduce this? If yes, can you try to record a http log and send the log to necko@mozilla.com?
Thanks.
Sent
|
|
||
Comment 4•2 years ago
|
||
Thanks for the log. I can see that the connection was really reset by the peer.
Since you said in the comment#0 that Firefox Nightly works, could you try to use mozregression to help us understand which change fixes this issue?
Thanks.
|
|
Reporter | |
Comment 5•2 years ago
|
||
I tried using 'mozregression' but I think I made a mistake. I compared between:
- buildID: 20240509170740 (v126.0) and buildID: 20240528001238 (v128.0a1)
milindh@Milindh-Razer:~$ mozregression --find-fix -b 20240509170740 -g 20240528001238
0:00.53 WARNING: Skipping build 2024-05-09 17:07:40: Unable to find build info for 2024-05-09 17:07:40
0:01.33 INFO: Testing good and bad builds to ensure that they are really good and bad...
0:01.33 INFO: Using local file: /home/milindh/reg/2024-05-28-00-12-38--mozilla-central--firefox-128.0a1.en-US.li>
0:01.33 INFO: Running mozilla-central build for buildid 20240528001238
0:10.30 INFO: Launching /tmp/tmp500tsfjj/firefox/firefox
0:10.30 INFO: Application command: /tmp/tmp500tsfjj/firefox/firefox -profile /tmp/tmpowafw1d2.mozrunner
0:10.31 INFO: application_buildid: 20240528001238
0:10.31 INFO: application_changeset: 046da0f065e90bcf67ec9fd58aa8f84c1a8f80be
0:10.31 INFO: application_name: Firefox
0:10.31 INFO: application_repository: https://hg.mozilla.org/mozilla-central
0:10.31 INFO: application_version: 128.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
0:20.53 INFO: Using local file: /home/milindh/reg/2024-05-10--mozilla-central--firefox-127.0a1.en-US.linux-x86_6>
0:20.53 INFO: Running mozilla-central build for 2024-05-10
0:29.66 INFO: Launching /tmp/tmpegwc0yko/firefox/firefox
0:29.66 INFO: Application command: /tmp/tmpegwc0yko/firefox/firefox -profile /tmp/tmpa2uqqwz3.mozrunner
0:29.67 INFO: application_buildid: 20240510213620
0:29.67 INFO: application_changeset: b09dd768d80e3ba321a5db4a0d534ea0c5385465
0:29.67 INFO: application_name: Firefox
0:29.67 INFO: application_repository: https://hg.mozilla.org/mozilla-central
0:29.67 INFO: application_version: 127.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
0:45.56 ERROR: Build was expected to be bad! The initial good/bad range seems incorrect.
- buildID: 20240509170740 (v126.0) and buildID: 20240527091822 (v127.0b7) [Because the website works on Developer edition as well]
milindh@Milindh-Razer:~$ mozregression --find-fix -b 20240509170740 -g 20240527091822
0:01.73 WARNING: Skipping build 2024-05-09 17:07:40: Unable to find build info for 2024-05-09 17:07:40
0:01.73 WARNING: Skipping build 2024-05-27 09:18:22: Unable to find build info for 2024-05-27 09:18:22
0:03.95 INFO: Testing good and bad builds to ensure that they are really good and bad...
0:03.95 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2024/05/2024-05-26-21-27-5>
===== Downloaded 100% =====
0:12.79 INFO: Running mozilla-central build for 2024-05-26
0:22.19 INFO: Launching /tmp/tmpdj6e8yhi/firefox/firefox
0:22.19 INFO: Application command: /tmp/tmpdj6e8yhi/firefox/firefox -profile /tmp/tmpri3lyfzx.mozrunner
0:22.20 INFO: application_buildid: 20240526212755
0:22.20 INFO: application_changeset: 222d646f13198a4c9e283516fbd040d65406bc01
0:22.20 INFO: application_name: Firefox
0:22.20 INFO: application_repository: https://hg.mozilla.org/mozilla-central
0:22.20 INFO: application_version: 128.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
0:31.80 INFO: Using local file: /home/milindh/reg/2024-05-10--mozilla-central--firefox-127.0a1.en-US.linux-x86_6>
0:31.80 INFO: Running mozilla-central build for 2024-05-10
0:41.32 INFO: Launching /tmp/tmps4f1ie77/firefox/firefox
0:41.32 INFO: Application command: /tmp/tmps4f1ie77/firefox/firefox -profile /tmp/tmpa1vls0vr.mozrunner
0:41.32 INFO: application_buildid: 20240510213620
0:41.32 INFO: application_changeset: b09dd768d80e3ba321a5db4a0d534ea0c5385465
0:41.32 INFO: application_name: Firefox
0:41.32 INFO: application_repository: https://hg.mozilla.org/mozilla-central
0:41.32 INFO: application_version: 127.0a1
Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good
0:50.73 ERROR: Build was expected to be bad! The initial good/bad range seems incorrect.
|
|
Reporter | |
Comment 6•2 years ago
|
||
(In reply to Kershaw Chang [:kershaw] from comment #4)
Thanks for the log. I can see that the connection was really reset by the peer.
Since you said in the comment#0 that Firefox Nightly works, could you try to use mozregression to help us understand which change fixes this issue?
Thanks.
I used a wider date range and this is what I could find:
|
|
||
Comment 7•2 years ago
|
||
(In reply to milindhvijay from comment #6)
(In reply to Kershaw Chang [:kershaw] from comment #4)
Thanks for the log. I can see that the connection was really reset by the peer.
Since you said in the comment#0 that Firefox Nightly works, could you try to use mozregression to help us understand which change fixes this issue?
Thanks.I used a wider date range and this is what I could find:
Thanks for doing this. It's interesting that enabling xyber768d00 fixes the issue.
I'll change the component and let PSM folks decide what to do next.
|
|
Reporter | |
Comment 8•2 years ago
|
||
(In reply to Kershaw Chang [:kershaw] from comment #7)
(In reply to milindhvijay from comment #6)
(In reply to Kershaw Chang [:kershaw] from comment #4)
Thanks for the log. I can see that the connection was really reset by the peer.
Since you said in the comment#0 that Firefox Nightly works, could you try to use mozregression to help us understand which change fixes this issue?
Thanks.I used a wider date range and this is what I could find:
Thanks for doing this. It's interesting that enabling
xyber768d00fixes the issue.
I'll change the component and let PSM folks decide what to do next.
I still don't 100% believe that is the primary reason for the issue. Probably because I don't know what xyber768d00 is or what it does. When I use my backup ISP, website works even on v126.0.
This is the curl output between both ISPs:
ISP 1:
curl -v https://ibb.co
* Host ibb.co:443 was resolved.
* IPv6: (none)
* IPv4: 213.174.132.224
* Trying 213.174.132.224:443...
* Connected to ibb.co (213.174.132.224) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* Recv failure: Connection reset by peer
* LibreSSL/3.3.6: error:02FFF036:system library:func(4095):Connection reset by peer
* Closing connection
curl: (35) Recv failure: Connection reset by peer
ISP2:
curl -v https://ibb.co
* Host ibb.co:443 was resolved.
* IPv6: (none)
* IPv4: 213.174.132.224
* Trying 213.174.132.224:443...
* Connected to ibb.co (213.174.132.224) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
* subject: CN=ibb.co
* start date: Apr 22 06:29:44 2024 GMT
* expire date: Jul 21 06:29:43 2024 GMT
* subjectAltName: host "ibb.co" matched cert's "ibb.co"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://ibb.co/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: ibb.co]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.6.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: ibb.co
> User-Agent: curl/8.6.0
> Accept: */*
>
< HTTP/2 301
< server: nginx
< date: Tue, 28 May 2024 12:23:38 GMT
< content-type: text/html
< content-length: 162
< location: https://imgbb.com/
< x-frame-options: DENY
< strict-transport-security: max-age=63072000; includeSubDomains; preload
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host ibb.co left intact
|
||
Comment 10•2 years ago
|
||
When xyber768d00 is enabled, we retry connections that hit a PR_CONNECT_RESET_ERROR as long as that error occurs before we receive the server's key share. So I suspect we'd still see the reset in a packet trace, and that this isn't really a PSM issue.
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 11•2 years ago
|
||
(In reply to John Schanck [:jschanck] from comment #10)
When xyber768d00 is enabled, we retry connections that hit a
PR_CONNECT_RESET_ERRORas long as that error occurs before we receive the server's key share. So I suspect we'd still see the reset in a packet trace, and that this isn't really a PSM issue.
If it's the ISP terminating connections, how can xyber768d00 retry until receiving the server's key? Unless xyber768d00 does different encryption on TLS handshake that my ISP can't inspect or interfere with, I assume?
Also, it's enabled on v127 and v128. Is there a way to enable it on stable v126?
|
|
||
Comment 12•2 years ago
|
||
You can set security.tls.enable_kyber on 126. But, for what it's worth, I don't think your ISP is changing its behavior based on the type of encryption that is used.
|
|
Reporter | |
Comment 13•2 years ago
|
||
(In reply to John Schanck [:jschanck] from comment #12)
You can set
security.tls.enable_kyberon 126. But, for what it's worth, I don't think your ISP is changing its behavior based on the type of encryption that is used.
Huh, so is this a firefox thing or not? Should I close this bug report and be asking my ISP to look into it?
|
|
||
Comment 14•2 years ago
|
||
It's still unclear to me why Chrome and Firefox Nightly work, but the Firefox release version does not. I think it would be great if we could figure this out. Could you try to record an HTTP log with Firefox Nightly again? I could compare it and see if I can find the difference.
Thanks.
|
|
Reporter | |
Comment 15•2 years ago
|
||
(In reply to Kershaw Chang [:kershaw] from comment #14)
It's still unclear to me why Chrome and Firefox Nightly work, but the Firefox release version does not. I think it would be great if we could figure this out. Could you try to record an HTTP log with Firefox Nightly again? I could compare it and see if I can find the difference.
Thanks.
Sent http logs from both v127 and v128 via mail.
|
|
||
Comment 17•2 years ago
|
||
(In reply to milindhvijay from comment #15)
(In reply to Kershaw Chang [:kershaw] from comment #14)
It's still unclear to me why Chrome and Firefox Nightly work, but the Firefox release version does not. I think it would be great if we could figure this out. Could you try to record an HTTP log with Firefox Nightly again? I could compare it and see if I can find the difference.
Thanks.Sent http logs from both v127 and v128 via mail.
I've looked at two logs, and both show that the request to https://ibb.co is served from the HTTP cache, which might suggest that Firefox Nightly working could be a false positive.
Given that curl is also not working, I think this is not a Firefox issue, although I can't explain why Chrome works.
|
|
Reporter | |
Comment 18•2 years ago
|
||
(In reply to Kershaw Chang [:kershaw] from comment #17)
(In reply to milindhvijay from comment #15)
(In reply to Kershaw Chang [:kershaw] from comment #14)
It's still unclear to me why Chrome and Firefox Nightly work, but the Firefox release version does not. I think it would be great if we could figure this out. Could you try to record an HTTP log with Firefox Nightly again? I could compare it and see if I can find the difference.
Thanks.Sent http logs from both v127 and v128 via mail.
I've looked at two logs, and both show that the request to https://ibb.co is served from the HTTP cache, which might suggest that Firefox Nightly working could be a false positive.
Given that curl is also not working, I think this is not a Firefox issue, although I can't explain why Chrome works.
You are right about request being server from HTTP cache but I do not think that is why it works on Firefox Nightly. I can spin up a VM and try to open it on Nightly and it works (Already tested this way).
As for chrome working, I checked and found that Kyber is enabled by default on Chrome (so is the case with all other chromium based browsers, verified on Brave and Arc. The website works on safari browser (on mac) as well but not on safari mobile. I do not know how to check for kyber status on safari.
Now the question is, how does it work with kyber enabled.
Description
•