Connection reset error on some secure sites in Fx36 Aurora

VERIFIED FIXED in Firefox 36

Status

()

defect
--
critical
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: mwobensmith, Assigned: emk)

Tracking

({regression})

36 Branch
mozilla38
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox36+ verified, firefox37 fixed, firefox38 fixed)

Details

Attachments

(1 attachment)

During a compat test of Fx36.0a2, build 20141230004009 vs latest shipping Fx34 and Fx35 beta,  the following three sites no longer work. An error appears saying the connection was reset.

https://airportwifi.com/ 
https://cart.pcpitstop.com/ 
https://books.wwnorton.com/

Note that the first site on this list does not open in Chrome either.

I've checked these three sites on the SSL Labs' site to examine TLS intolerance, but that's not the issue. I'm hoping someone else with more understanding of recent changes can enlighten me as to what is going on.
Dunno if related to bug 1084025 or not, so not marking as dependent just yet.
Summary: Connection reset on some sites in Fx36 Aurora → Connection reset error on some secure sites in Fx36 Aurora
OS: Mac OS X → All
Hardware: x86 → All
Blame these on bug 1084025, they are all TLS 1.2 intolerant sites.

That said, I think that this is worth looking into for bug 1088915, because I didn't see a fallback to a handshake that included RC4 as an option.
Blocks: 1084025, 1088915
Flags: needinfo?(VYV03354)

Comment 3

4 years ago
AFAIK IE11 always adds the RC4 cipher suites on a TLS 1.0 fallback.
(In reply to Yuhong Bao from comment #3)
> AFAIK IE11 always adds the RC4 cipher suites on a TLS 1.0 fallback.

That's right, the IE fallback path is TLS 1.2 (no RC4) -> TLS 1.0 (no RC4) -> TLS 1.0 (RC4).  But the fact that they choose to fall back is key here.  As configured in Fx36, we should try with TLS 1.2 twice, once without RC4 and once with.  I'm not seeing the second one.

Comment 5

4 years ago
BTW, I noticed that all three servers are running IIS. I wonder if anyone can disable all but RC4 suites in a test IIS server using something like:
https://www.nartac.com/Products/IISCrypto/Default.aspx
(Assignee)

Comment 6

4 years ago
The connection failed even if I set the version fallback limit to 1 (TLS 1.0). At the moment, we don't fallback with RC4 if the error code was NS_ERROR_CONNECTION_RESET.
No longer blocks: 1084025
Flags: needinfo?(VYV03354)
(Assignee)

Comment 7

4 years ago
Keeler is on vacation. Who can review this?
Also, I'm not sure we should really need this. Two of those sites are just a redirect to http:// URL.
(Assignee)

Updated

4 years ago
Duplicate of this bug: 1116892
Comment on attachment 8543139 [details] [diff] [review]
bug1116891_fallback_with_rc4_if_PR_CONNECT_RESET_ERROR

Review of attachment 8543139 [details] [diff] [review]:
-----------------------------------------------------------------

I wonder if this path is worth pursuing anyway.  No doubt we will continue to find various forms of intolerance until the list of errors looks much the same as the version intolerance list.  I don't know how to assess whether we want the fix the browser or ask to have the site fixed here anyway.  I'm inclined to suggest that we take the latter option, unless these have a large number of users.

Either way, this can probably wait a few days.  36 becomes beta on the 13th, I think.  No sense rushing a fix out.

Comment 10

4 years ago
(In reply to Martin Thomson [:mt] from comment #9)
> No doubt we will continue
> to find various forms of intolerance until the list of errors looks much the
> same as the version intolerance list.

For example...

In bug 1116892 a similar issue was discovered.

https://cualerts.dupaco.com/

It is effectively RC4 only and results in an NS_ERROR_NET_INTERRUPT error.

It too shows as IIS (6.0, to be precise).

Comment 11

4 years ago
Disregard comment 10. Bug 1116892 was duped here as I was fixing my mid-flight collision with comment 9. Apparently this patch here fixes that too.

Comment 12

4 years ago
https://emaildvla.direct.gov.uk/ is also not working in Firefox Nightly. Per ssllabs.com they use TLS_RSA_WITH_RC4_128_MD5. I contacted gov.uk but they redirected me back to https://emaildvla.direct.gov.uk/emaildvla/cegemail/dvla/en/driver_5.html which I have not bothered to fill in due to the amount of details requested.

Comment 13

4 years ago
They are also TLS 1.2 intolerant. Does this site work in Aurora?
See Also: → 1117157
These sites also. Same cause as above, it appears - they use TLS_RSA_WITH_RC4_128_MD5.

https://www.gosignmeup.com/ 
https://m.getawaytoday.com/
:emk, does the patch in this bug need check-in?
Flags: needinfo?(VYV03354)
(Assignee)

Comment 16

4 years ago
(In reply to David Keeler [:keeler] (use needinfo?) from comment #15)
> :emk, does the patch in this bug need check-in?

It's my understanding that it will be decided after testing on beta for a few days.
Flags: needinfo?(VYV03354)
Hi Masatoshi, do we know what causes these sites to fail if it is not the TLS fallback change in bug 1084025? Since these sites definitely fail in Fx36 beta - and not Fx35 - something must have changed. 

I guess I'm wondering whether you should use your patch to address the issue here? Or if we should investigate further to see what we regressed in Fx36 to cause this and fix that?
Flags: needinfo?(VYV03354)
(Assignee)

Comment 18

4 years ago
These sites fail not because TLS *version* fallback is disabled, but because we don't fallback with RC4 cipher suites for connection reset (bug 1088915). The patch is already attached in this bug and r+'ed.

But if we are going to kill RC4 according to soon-to-be-published RFC, we should not land this patch.
Flags: needinfo?(VYV03354)
(Assignee)

Updated

4 years ago
Blocks: 1127285
Masatoshi, so, do you know what is plan for this bug?
Assignee: nobody → VYV03354
Flags: needinfo?(VYV03354)
(Assignee)

Comment 20

4 years ago
I'll land this bug along with bug 1127285 on Nightly and Aurora, and land just this bug on Beta.
Flags: needinfo?(VYV03354)
(Assignee)

Updated

4 years ago
Blocks: 1128763
(Assignee)

Updated

4 years ago
No longer blocks: 1127285
We are going to build beta 7 pretty soon. Could you fill the uplift request to aurora & beta right now? Thanks
Flags: needinfo?(VYV03354)
(Assignee)

Comment 23

4 years ago
Comment on attachment 8543139 [details] [diff] [review]
bug1116891_fallback_with_rc4_if_PR_CONNECT_RESET_ERROR

Approval Request Comment
[Feature/regressing bug #]: bug 1088915
[User impact if declined]: Users can not connect some sites without any workarounds.
[Describe test coverage new/current, TreeHerder]: Manually tested
[Risks and why]: Very low. This change will only affect tiny fractions of sites.
[String/UUID change made/needed]: none
Flags: needinfo?(VYV03354)
Attachment #8543139 - Flags: approval-mozilla-beta?
(Assignee)

Comment 24

4 years ago
Comment on attachment 8543139 [details] [diff] [review]
bug1116891_fallback_with_rc4_if_PR_CONNECT_RESET_ERROR

Oops, forgot to flag approval‑mozilla‑aurora.

Approval Request Comment
See the above approval request to beta.
Attachment #8543139 - Flags: approval-mozilla-aurora?
Attachment #8543139 - Flags: approval-mozilla-beta?
Attachment #8543139 - Flags: approval-mozilla-beta+
Attachment #8543139 - Flags: approval-mozilla-aurora?
Attachment #8543139 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/1ec993f3e8bf
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Verified fixed in Fx36 using previously broken sites above.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.