1710202 - An error occurred during a connection to https://www.mozilla.org/en-US/firefox/new/. PR_END_OF_FILE_ERROR

Status: UNCONFIRMED

(NSS :: Libraries, defect, P5)

Description

[alizare777]

Attachment: a.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

when i try to browse to https://www.mozilla.org/en-US/firefox/new/ or some other address.

Actual results:

i receive, Secure Connection Failed "PR_END_OF_FILE_ERROR"

Expected results:

expected to open that site normally.

Comment 1

[Gingerbread Man]

Please go through the troubleshooting steps at
https://support.mozilla.org/en-US/questions/1267074#answer-1246714

Comment 2

[alizare777]

i run firefox in safe mode.
i disable hardware acceleration.
but i receive same error in firefox in home or at work pc.

Comment 3

[alizare777]

Attachment: web site security error

Comment 4

[alizare777]

Attachment: 2.png

Comment 5

[alizare777]

Attachment: firefox options

Comment 6

[alizare777]

Attachment: firefox extenstions

Comment 7

[alizare777]

i run firefox in safe mode.
i disable hardware acceleration.
i haven't any third party antivirus.
i disable windows 10 virus & threat protection.
i haven't any proxy or vpn on my devices.
but i receive same error in my laptop and desktop.

i love firefox, and i using it more than 15 year.

Comment 8

[(inactive) Nihanth Subramanya [:nhnt11]]

Thanks for reporting the bug! Some questions:

1. Is this issue happening every single time you try to load this site? Or just sometimes? If there are any other sites which are affected, could you share which ones?
2. Could you get a http log please? You can share a google drive or dropbox etc link if it's too big to attach here.

Comment 9

[alizare777]

After the recent update, I have this problem almost all the time. And I can rarely be without problems.

I only use very few sites. And the site I work with a lot is wallex.ir. That site has the same problem.

I have access to these sites from Iran. I subscribe with two different ISPs. But I have this problem with both of them.

I sent you the log files.

Comment 10

[alizare777]

Attachment: log file

Comment 11

[Dariush]

This problem happened to me after updating to Firefox 88.0.1 on Ubuntu 20.04 .
All recommended solutions have been supported by Mozilla Firefox but there is still a problem.
I also used the latest "Firefox Beta, Nightly, ESR" versions ; but the problem was not fixed.
This problem does not occur with Firefox using VPN.

Also, this problem does not occur in Google Chrome.

For example, some websites that have this problem:
"mozilla.org/en-US/firefox/all",
"bugzilla.mozilla.org",
"virgool.io"

Comment 12

[Kershaw Chang [:kershaw]]

(In reply to alizare777 from comment #9)

After the recent update, I have this problem almost all the time. And I can rarely be without problems.

I only use very few sites. And the site I work with a lot is wallex.ir. That site has the same problem.

I have access to these sites from Iran. I subscribe with two different ISPs. But I have this problem with both of them.

I sent you the log files.

This looks like a issue related to firewall or some middle box. Have you tried to reproduce this with other browsers?
If you use VPN software to connect to another network, are you still able to see this issue?

Comment 13

[Dariush]

(In reply to Kershaw Chang [:kershaw] from comment #12)

This looks like a issue related to firewall or some middle box. Have you tried to reproduce this with other browsers?
If you use VPN software to connect to another network, are you still able to see this issue?

• This problem does not occur with Firefox using VPN.
• This problem does not occur in Google Chrome (even without using a vpn ).
• This problem exists in different ISPs.

Comment 14

[Kershaw Chang [:kershaw]]

Switch the component to NSS, since it seems PR_END_OF_FILE_ERROR is mostly set in NSS lib.

Comment 15

[Ali Shamakhi]

I can confirm the problem exists for various domains (mozilla.org , bitwarden.com , steamcommunity.com , etc.), while other browsers (e.g. Microsoft Edge) on the same system have no problem, all while not using any proxy/VPN connection. Also I have refreshed Firefox and created another profile (at about:profiles) and the same problem exists.

What is interesting about the problems is that it will not happen while USING a proxy/VPN connection. I had DNS-over-HTTPS settings off all the time, but I'm suspecting that maybe a similar resolution mechanism is related to the problem.

There is no report of ISP-related connectivity issues AFAIK. (https://explorer.ooni.org/search?probe_cc=IR&domain=www.mozilla.org)

Comment 16

[Dragana Damjanovic [:dragana]]

Can someone make a wireshare capture? Please if possible make a capture of a failing connection using Firefox and a connection using Chrome.

The connections are failing during TLS handshakes. TLS records may differ between browsers. We need to figure out why a connection using Firefox fails.

Comment 17

[Dariush]

(In reply to Dragana Damjanovic [:dragana] from comment #16)

wireshare capture files:

https://filebin.net/3pw0ohurywdnfum5/firefox88.0.1_ubuntu20.04-amd64_SecureConnectionFailed-PR_END_OF_FILE_ERROR.pcap

https://filebin.net/3pw0ohurywdnfum5/chrome90.0.4430.212_ubuntu20.04-amd64_NoProblem.pcap

Comment 18

[Martin Thomson [:mt:]]

I'm not seeing anything there that would be cause for alarm. There are differences, but nothing alarming. We support more ciphers, signature schemes, and key exchange algorithms. Chrome greases. We send two key shares, Chrome one. Everything there points to our ClientHello being more compatible.

I do note that the successful trace uses "mozilla.org" at first. The unsuccessful one uses "www.mozilla.org". But Chrome seems to get a redirect to "www.mozilla.org". I think that Firefox also does the same, and are getting the connection through, but the trace is missing part of the ServerHello flight. So the "mozilla.org" connection seems to have worked and the "www.mozilla.org" connection (which the first redirects to) fails.

The other thing of note is that there are lots of retransmissions in a short time. Both browsers send out lots of retransmissions. That shouldn't affect things either, but the duplicate ACKs indicate that something might be reordering packets.

My intuition here is that we are seeing interference from a middlebox. This is a Cloudflare endpoint, so it seems unlikely that this is busted. The screams would be much louder if it was.

Comment 19

[Dariush]

(In reply to Martin Thomson [:mt:] from comment #18)

My intuition here is that we are seeing interference from a middlebox. This is a Cloudflare endpoint, so it seems unlikely that this is busted. The screams would be much louder if it was.

But why does this problem only occur in Firefox?

Thank you for your response.

Comment 20

[Martin Thomson [:mt:]]

We're talking to folks at Cloudflare about this.

Is DoH enabled? Can you try disabling DoH and trying again?

about:networking#dnslookuptool can be used to show what www.mozilla.org resolves to. The answer with and without DoH - if it is different - would be interesting.

Comment 21

[(inactive) Nihanth Subramanya [:nhnt11]]

+1 on Martin's question about whether www.mozilla.org is resolving to different addresses with and without DoH.

Also, it might be helpful to know if you are in a region of the world where internet censorship is in effect.

Comment 22

[Ali Shamakhi]

The issue seems to be resolved from my end.

@[e-mail]
The result of resolving www.mozilla.org is the same with and without DoH (Cloudflare): 104.18.164.34, 104.18.165.34

@[e-mail]
Yes, there is censorship in effect in my region.

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

Redirect needinfos that are pending on inactive users to the triage owner.
:beurdouche, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.