1398424 - accounts.firefox.com Secure Connection Failed, but only in Firefox

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect)

Description

[Qwerty]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053622

Steps to reproduce:

That started 2 years ago, probably because awry government censorship. I know you can't reproduce, but the thing is that other browsers aren't affected and Firefox 54 wasn't affected too (not sure it's first ok version, I had not checked every version with disabled proxying for that domain). 55 returned this problem. Last Nightly still affected too.
I checked 54 and 55 simultaneously with clean profiles when 55 version came, this difference is not caused by change in my environment or ISP. 54 just opens https://accounts.firefox.com normally and 55 can't (Sync not working either).
In Chrome I see valid certificate by DigiCert, exactly the same as I see via web tools (ssllabs).
Something changed from 54 to 55? Can I help with investigation? HAR log from Network Monitor is almost empty though.


Actual results:

"Secure Connection Failed. The connection to the server was reset while the page was loading."


Expected results:

Domain should open normally

Comment 1

[Kohei Yoshino [:kohei]]

Please visit https://support.mozilla.org/questions/firefox to get help.

Comment 2

[Qwerty]

(In reply to Kohei Yoshino [:kohei] from comment #1)
> Please visit https://support.mozilla.org/questions/firefox to get help.

I did it :C https://support.mozilla.org/en-US/questions/1171049
> 8/11/17
> 1 view

Comment 3

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Maybe you're using some security or protection software like antivirus or firewall.
So disable HTTPS/HTTP scanning in AV/FW and disable AV/FW addon in Firefox,
as AV/FW shouldn't eavesdrop and intercepting any connection, especially HTTPS, as it's security and privacy issue [1][2]

[1] = https://zakird.com/papers/https_interception.pdf
[2] = https://bugs.chromium.org/p/project-zero/issues/detail?id=978

Comment 4

[Qwerty]

No. I have firewall, but it does not intercept HTTP/HTTPS traffic, just controls if programs can make connection or they are blocked. As writed above, I see valid DigiCert certificate in Chrome and Firefox 54 on same computers.

Comment 5

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

You may want to try:
- changing DNS, to see if it's some kind of censorship
- Firefox 55 Portable, to see it it's really Firefox issue
- mozregression GUI[1], to search for specific patch which could cause this issue, see [2] for some FAQ


[1] = https://github.com/mozilla/mozregression/releases
[2] = https://mozilla.github.io/mozregression/quickstart.html

Comment 6

[Qwerty]

OpenNIC/Google/Yandex DNS is the same (cache flushed).
Portable ff55.0.3 is the same.
I will try mozregression, but my internet is slow and limited, so it will take time.

Comment 7

[Qwerty]

I did mozregression. Result:


INFO : Narrowed inbound regression window from [55226777, c206ddf4] (3 builds) to [8c24ffa3, c206ddf4] (2 builds) (~1 steps left)
DEBUG : Starting merge handling...
DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=c206ddf4676cf7d57aeabf284e99035c9c046d84&full=1
DEBUG : Found commit message:
Bug 1345368 - land NSS 215207b4864c, r=me

INFO : The bisection is done.
INFO : Stopped

Comment 8

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Thanks!

Comment 9

[Franziskus Kiefer [:franziskus]]

I just tried to connect to accounts.firefox.com with Firefox 55.0.3 (32-bit and 64-bit versions) on Windows 10 and it worked fine. So this must either be a Windows 7 specific issue or there's something installed that prevents Firefox from making this connection.
Given the error message "The connection to the server was reset while the page was loading" and the statement "my internet is slow and limited" this could also be some other issue where the connection needs too long to get established.

Looking at the changes in NSS that landed in the regression range from comment 7 I don't see anything that could've caused this.

Comment 10

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Maybe getting some info with Fiddler and Wireshark could help.

Comment 11

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Looks like that particular changeset touched how NSS does padding: https://hg.mozilla.org/integration/mozilla-inbound/rev/c206ddf4676cf7d57aeabf284e99035c9c046d84#l23.30
qwerty - can you use wireshark to capture the packets of a TLS handshake to accounts.firefox.com?

Comment 12

[Tim Taubert [:ttaubert] (inactive)]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #11)
> Looks like that particular changeset touched how NSS does padding:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/
> c206ddf4676cf7d57aeabf284e99035c9c046d84#l23.30

This would be bug 1350576 then.

Comment 13

[Qwerty]

Attachment: wireshark capture

(In reply to David Keeler [:keeler] (use needinfo?) from comment #11)
> Looks like that particular changeset touched how NSS does padding:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/
> c206ddf4676cf7d57aeabf284e99035c9c046d84#l23.30
> qwerty - can you use wireshark to capture the packets of a TLS handshake to
> accounts.firefox.com?

Is this helpful? The change I see in ClientHello is really padding. Last good build has padding before SNI and doesn't receive RST flag. Also included Chrome capture.

Comment 14

[Tim Taubert [:ttaubert] (inactive)]

Looks like *something* can't handle the SNI being the first extension...

qwerty, do you happen to have another machine in the same network with Win 7 x64? I wonder if this is a network/middlebox issue or something on the machine itself that tries to intercept/inspect traffic?

Comment 15

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Tim Taubert [:ttaubert] from comment #14)
> qwerty, do you happen to have another machine in the same network with Win 7
> x64? I wonder if this is a network/middlebox issue or something on the
> machine itself that tries to intercept/inspect traffic?

I actually meant to ask you to please try to reproduce this on another machine in the same network, if possible :) A Linux live CD would work too if you don't have another machine at hand.

Comment 16

[Qwerty]

(In reply to Tim Taubert [:ttaubert] from comment #14)
> qwerty, do you happen to have another machine in the same network with Win 7
> x64? I wonder if this is a network/middlebox issue or something on the
> machine itself that tries to intercept/inspect traffic?

Yes, second PC on Win7 x64 with same problem. Other users in my country, at least from the same ISP (biggest one), also complained about this.
I'll try Live Ubuntu later, it's probably not OS-related.

Comment 17

[Qwerty]

Attachment: Ubuntu Screenshot

I tried live usb Ubuntu 16.04.3 LTS 32-bit, and for some reasons even built-in Firefox 54.0 (32-bit) has this problem.

Comment 18

[Tim Taubert [:ttaubert] (inactive)]

Thanks qwerty! Not sure what exactly we can do about this. It seems that your ISP is inspecting packets (to extract the SNI from TLS connections?) and then unfortunately breaks the connection when their parser fails. Can you name the ISP you're using? (No is an answer too, that would be fine :)

Martin, any opinion? Should we try to figure out how many users are affected and possibly revert bug 1350576? Or try to find a different solution?

Comment 19

[Qwerty]

(In reply to Tim Taubert [:ttaubert] from comment #18)
> Can you name the ISP you're using? (No is an answer too, that would be fine :)

I can answer privately, if that helps. Should I mail you?

(In reply to qwerty from comment #17)
> I tried live usb Ubuntu 16.04.3 LTS 32-bit, and for some reasons even
> built-in Firefox 54.0 (32-bit) has this problem.

I tried official 54.0.1 build for Linux and looked in wireshark: both canonical and official 54 have SNI as the first extension, unlike on Windows in 54, probably because length is less than 256 and padding is not used at all, while on Windows length was 512. So that's why they suffered this problem too.

By the way, in https://tools.ietf.org/html/rfc5246#section-7.4.1.4 I see:
> When multiple extensions of different types are present in the ClientHello or ServerHello messages, the extensions MAY appear in any order.
Is that still in force?

Comment 20

[Tim Taubert [:ttaubert] (inactive)]

(In reply to qwerty from comment #19)
> (In reply to Tim Taubert [:ttaubert] from comment #18)
> > Can you name the ISP you're using? (No is an answer too, that would be fine :)
> 
> I can answer privately, if that helps. Should I mail you?

Feel free to email me, or message "ttaubert" on IRC.

> (In reply to qwerty from comment #17)
> > I tried live usb Ubuntu 16.04.3 LTS 32-bit, and for some reasons even
> > built-in Firefox 54.0 (32-bit) has this problem.
> 
> I tried official 54.0.1 build for Linux and looked in wireshark: both
> canonical and official 54 have SNI as the first extension, unlike on Windows
> in 54, probably because length is less than 256 and padding is not used at
> all, while on Windows length was 512. So that's why they suffered this
> problem too.

Yeah, that makes sense.

> By the way, in https://tools.ietf.org/html/rfc5246#section-7.4.1.4 I see:
> > When multiple extensions of different types are present in the ClientHello or ServerHello messages, the extensions MAY appear in any order.
> Is that still in force?

The spec doesn't require a specific extension order, however various TLS stacks aren't quite that flexible in reality.

Comment 21

[Panos Astithas (he/him) [:past] (please ni?)]

David, do we have data on how prevalent this issue is? Is this dot-release-worthy?

Comment 22

[Dana Keeler (she/her) (use needinfo) [:keeler]]

We probably won't know until we know what ISP it is.

Comment 23

[Tim Taubert [:ttaubert] (inactive)]

Received the email with info about the ISP. Will forward internally.

Comment 24

[Qwerty]

By the way, seems like my ISP changed something about one month ago and the problem is gone for now. Hopefully forever.

Comment 25

[Martin Thomson [:mt:]]

That's a relief.  I'm glad that we didn't have to do something for this; it's very difficult to make any sort of change here without risking more compatibility problems.  Thanks for reporting this.