This is a new bug that appeared in Nightly within the last few days. To see it, go to http://www.southstatebank.com, enter an email address (which does not need to be real) in "Access ID" and click "LOG IN". I tried many things to get rid of it but nothing worked until I tried using "Firefox" (version 34) instead of "Nightly". It worked using exactly the same profile, so nothing in the profile was a problem. I get the same error in "safe mode", so it does not seem to be my add-ons either.

Reproduces on Windows as well. If you know this is a recent regression, can you try finding a range using mozregression? ( http://mozilla.github.io/mozregression/ )

17:13.07 LOG: MainThread Bisector INFO Oh noes, no (more) inbound revisions :( 17:13.07 LOG: MainThread Bisector INFO Last good revision: 77411a7f31ed 17:13.07 LOG: MainThread Bisector INFO First bad revision: 5b01216f97f8 I'm not 100% sure I trust this, but that is what it said.

(In reply to Jonathan Baron from comment #2) > 17:13.07 LOG: MainThread Bisector INFO Oh noes, no (more) inbound revisions > :( > 17:13.07 LOG: MainThread Bisector INFO Last good revision: 77411a7f31ed > 17:13.07 LOG: MainThread Bisector INFO First bad revision: 5b01216f97f8 > > I'm not 100% sure I trust this, but that is what it said. Yeah, was there no mozilla-central "pushlog" URL in the output?

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=77411a7f31ed&tochange=5b01216f97f8 I didn't know that was important. Sorry

(In reply to Jonathan Baron from comment #4) > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=77411a7f31ed&tochange=5b01216f97f8 > > I didn't know that was important. Sorry No worries. That range is a little odd, I think... I found this on m-c with the help of your already having narrowed it down: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f1f48ccb2d4e&tochange=5b01216f97f8 Still looking for inbound...

(In reply to :Gijs Kruitbosch from comment #5) > > Still looking for inbound... Is this something I am supposed to do?

(In reply to Jonathan Baron from comment #6) > (In reply to :Gijs Kruitbosch from comment #5) > > > > > Still looking for inbound... > > Is this something I am supposed to do? The brevity and un-clarity of the English language strikes again! Sorry for being unclear. No, I meant to say that I'm doublechecking the inbound regression range, because like you, I have doubts - not least because I don't see anything blindingly obvious even in the mozilla-central range. :-)

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=33592fd41f1f&tochange=38616c7e2da9 Masatoshi-san, any idea what's going on here? Half your patch was just a pref change, but in general, it seems we're looking at uplifting this, and so the in-the-wild breakage is kind of scary. David/Brian, thoughts?

https://www.ssllabs.com/ssltest/analyze.html?d=southstatebank.com Hmm, the site supports TLS 1.2 and is tolerant at even higher versions. It's possible that our fallback logic has a bug or some intermediates between the reporter and the bank are TLS intolerant.

The server involved is this: https://www.ssllabs.com/ssltest/analyze.html?d=web3.secureinternetbank.com It has TLS 1.2 intolerance.

(In reply to Yuhong Bao from comment #10) > The server involved is this: > https://www.ssllabs.com/ssltest/analyze.html?d=web3.secureinternetbank.com > It has TLS 1.2 intolerance. Thanks, I overlooked the STR.

The workaround is flipping back the "security.tls.version.fallback-limit" pref to 1. And we should evangelize the site or seek any other workarounds before flipping back the pref.

(In reply to Masatoshi Kimura [:emk] from comment #12) > The workaround is flipping back the "security.tls.version.fallback-limit" > pref to 1. > And we should evangelize the site ... Let me know if I can help with this. I would need to know exactly what to say. I am a customer of that bank (although I don't live there).

(In reply to Jonathan Baron from comment #13) > Let me know if I can help with this. I would need to know exactly what to > say. I am a customer of that bank (although I don't live there). Thank you. Here's the details: When connecting to secure sites, Firefox is saying "I support up to TLS 1.2". Servers don't have to support TLS 1.2 to establish a connection to Firefox. If the servers only support lower versions, they can select the highest version they support. This is called as TLS version negotiation. But a few servers do not support the version negotiation correctly. If they see the higher version number they know, they will panic and disconnect the TCP connection abruptly instead of negotiating the version. Those servers are called as "TLS intolerant". web3.secureinternetbank.com an example of TLS intolerant servers at TLS 1.2. To keep compatibility with TLS intolerant servers, Firefox used to retry the connection with declaring lower max versions until Firefox succeeds to connect or the max version reached to TLS 1.0 and gives up. This is called as non-secure fallback. We are going to drop non-secure fallback because it is non-secure (as the name implies) and our statistics show that only <1% servers are intolerant at TLS 1.2 now. Usually the sites will have to upgrade the server or the network equipment to fix the TLS intolerance. Again, they don't have to support TLS 1.2 although it is recommended. Until the site is fixed, you can set the "security.tls.version.fallback-limit" pref value to "1" in about:config to access the site. This pref change will reenable the non-secure fallback. Perhaps Mozilla should prepare an add-on like SSL Version Control to mitigate the compatibility risk. Don't hesitate to ask any questions.

According to https://www.ssllabs.com/ssltest/analyze.html?d=southstatebank.com, the site isn't TLS intolerant at all. SSL Labs uses a different ClientHello than Firefox to determine whether or not a site is TLS intolerant, so this might be something that needs to be changed in Firefox's ClientHello to improve compatibility. I noticed that ssllabs says that the site prefers RC4 cipher suites. I also noticed that Google Chrome doesn't say anything about the site requiring non-secure version fallback in the connection details when it loads the site. This again indicates the problem is with Firefox's ClientHello, and not with the site being version intolerant. Note that Chrome negotiates an RC4 cipher suite for the site. So, the root cause might actually be related to bug 1088915. In particular, the set of reasons why we would fall back to the RC4-enabled handshake probably needs to be increased to include more of the error codes that triggered version fallback prior to bug 1084025.

Sorry, I should have tested web3.secureinternetbank.com. Hoewver, the results are similar: Although SSL Labs indicates that the site is TLS 1.2 intolerant, Google Chrome does not indicate that there was any version intolerance. And, this site also site prefers RC4 cipher suites. So, I still suspect that the logic in bug 1088915 likely needs to be improved to enable RC4 cipher suites in more circumstances.

(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #16) > Sorry, I should have tested web3.secureinternetbank.com. Hoewver, the > results are similar: Although SSL Labs indicates that the site is TLS 1.2 > intolerant, Google Chrome does not indicate that there was any version > intolerance. And, this site also site prefers RC4 cipher suites. So, I still > suspect that the logic in bug 1088915 likely needs to be improved to enable > RC4 cipher suites in more circumstances. My Chrome 39 does indicate version intolerance with https://web3.secureinternetbank.com/

I can't connect https://web3.secureinternetbank.com/ using Firefox 34 (that is, without RC4 fallback logic at all) if i set security.tls.version.fallback-limit to 3 and restart Firefox to forget the intolerance info. So I don't think improving the logic in bug 1088915 will help to access this site.

Thanks for checking. Sorry for the false lead.

Minor mass change for dependencies of bug 1126620. (filter on {bf0YGqIfJDgVDlKn3zYc}) As of bug 1114816, these sites are now whitelisted to allow for insecure fallback due to TLS version intolerance. Whilst these sites should now work with the patch applied, these bugs themselves are not actually FIXED until the server is. Moving all of these into the TE product for tracking.

As far as I can tell, there are several web*.secureinternetbank.com domains, all run by the company Fiserv, Inc for various banks. Some of them are RC4 only: e.g. https://www.ssllabs.com/ssltest/analyze.html?d=web2.secureinternetbank.com Some of them are RC4 only and TLS 1.2 intolerant: e.g. https://www.ssllabs.com/ssltest/analyze.html?d=web3.secureinternetbank.com And some seem to work fine. I have contacted Fiserv about the issues they will run into, and pointed them at this bug.

Seems that the ones that support secure renegotiation are still TLS 1.3 intolerant with 0x0304 in the record layer, can anyone test TLS 1.3 intolerance with 0x0301 in the record layer?

If [1] is approved, we will no longer be bothered by TLS 1.3+ intolerance. [1] https://www.ietf.org/mail-archive/web/tls/current/msg15748.html

All the servers looked fixed.