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.

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.

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.

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

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.

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.

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.

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

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.

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.

They are also TLS 1.2 intolerant. Does this site work in Aurora?

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?

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

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?

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.

Masatoshi, so, do you know what is plan for this bug?

I'll land this bug along with bug 1127285 on Nightly and Aurora, and land just this bug on Beta.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=69e7e86ec809 https://hg.mozilla.org/integration/mozilla-inbound/rev/1ec993f3e8bf

We are going to build beta 7 pretty soon. Could you fill the uplift request to aurora & beta right now? Thanks

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

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.

https://hg.mozilla.org/releases/mozilla-aurora/rev/45428bbaa4ee https://hg.mozilla.org/releases/mozilla-beta/rev/886561600f49

Verified fixed in Fx36 using previously broken sites above.