There is a recent regression in Firefox when loading coastcapitalsavings.com. The page used to load fine but in a recent Nightly it now just displays an SSL error. I tried going back to the January 15, 2015 Nightly and the page loads fine. I will see if I can track down the regression window.

This is a TLS intolerance issue: https://www.ssllabs.com/ssltest/analyze.html?d=www.coastcapitalsavings.com&s=208.69.252.179 In particular, see this line: > TLS version intolerance TLS 1.1 TLS 1.2 TLS 1.3 TLS 1.98 TLS 2.98 PROBLEMATIC FWIW, this site also appears to be RC4 only.

Last good revision: 2cb22c058add First bad revision: 3094601af679 Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2cb22c058add&tochange=3094601af679 Perhaps this could be caused by bug 1126413?

(In reply to Cykesiopka from comment #1) > This is a TLS intolerance issue: > https://www.ssllabs.com/ssltest/analyze.html?d=www.coastcapitalsavings. > com&s=208.69.252.179 > > In particular, see this line: > > TLS version intolerance TLS 1.1 TLS 1.2 TLS 1.3 TLS 1.98 TLS 2.98 PROBLEMATIC > > FWIW, this site also appears to be RC4 only. Does that mean this is an issue that Coast Capital Savings needs to fix on their end?

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #3) > (In reply to Cykesiopka from comment #1) > > This is a TLS intolerance issue: > > https://www.ssllabs.com/ssltest/analyze.html?d=www.coastcapitalsavings. > > com&s=208.69.252.179 > > > > In particular, see this line: > > > TLS version intolerance TLS 1.1 TLS 1.2 TLS 1.3 TLS 1.98 TLS 2.98 PROBLEMATIC > > > > FWIW, this site also appears to be RC4 only. > > Does that mean this is an issue that Coast Capital Savings needs to fix on > their end? Well, I withdraw my assertion that this is because of TLS intolerance (it may or may not be), but yes, the issues need to be fixed on the server end eventually.

Okay, I will reach out to their webmaster to inform them of this issue.

Bug 1126413 shouldn't change the behavior. Maybe bug 1124039? Anyway, the site should fix the issue as Cykesiopka said.

This is an problem with my bank's website as well; for the moment I'll be adding them to security.tls.insecure_fallback_hosts in addition to letting them know about the issue.

[Tracking Requested - why for this release]: Nominating for tracking since this could become a larger support issue as Firefox 38 gets closer to release, assuming multiple banks are affected and don't fix it in time.

We definitely want to keep an eye on this and it will also impact ESR. Matt - is this something sec QA can work on, pre-check popular banking websites so we have an idea of what to expect and can get ahead of some Tech Evangelism?

Bug 1124039 looks suspect, as the site here attempts to connect with TLS 1.0 and the RC4 cypher. Haven't read all of the related bugs there, so I can't say for sure. As with any TLS/SSL change, this requires compatibility testing. However, I think we first should find out if bug 1124039 indeed is the issue. If so, I'll focus my testing and results in that bug and we can make this one a dependency. Masatoshi, can you confirm? Thank you.

I can't connect www.coastcapitalsavings.com without enabling RC4 even if the fallback limit is 1. I can connect www.coastcapitalsavings.com with RC4 enabled even if the fallback limit is 3. Bug 1124039 will disable RC4 unless the site is whitelisted. So definitely RC4 is the issue, not a TLS intolerant issue. (I don't know why SSL Labs claims the TLS intolerance, but SSL Labs is not always accurate.)

(In reply to Masatoshi Kimura [:emk] from comment #11) > (I don't know why SSL Labs > claims the TLS intolerance, but SSL Labs is not always accurate.) SSL Labs uses 0x0303 for both the record-level version number and client_version for its ClientHello, like MSIE and Java. NSS uses 0x0301 for the record layer and 0x0303 for client_version. According to one study, the SSL Labs way has ~5% more intolerance than the NSS way. Also, some other aspects of the SSL Labs ClientHello may be different.

The site uses TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA now.

Verified fixed with Firefox Nightly 39.0a1 20150302030204.

Cleaning up the flags on this bug since it was a server-side issue and not a Firefox bug.