STR: 1. Try to load https://panel.dreamhost.com/ RESULT: Error page: "The connection was interrupted. The connection to panel.dreamhost.com was interrupted while the page was loading." I believe is a regression in Nightly 36 build 2014-11-01. I tried to bisect the regression further, but my test results are inconsistent. https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6bd2071b373f&tochange=b695d9575654

Perhaps bug 1088915?

I emailed DreamHost support to get their TLS act together. My tracking # there is 6550462.

(In reply to Anne (:annevk) from comment #2) > I emailed DreamHost support to get their TLS act together. My tracking # > there is 6550462. Thanks for doing that Anne. This is probably a combination of bug 1088915 AND bug 1084025. Though a compliant server will not trigger this behaviour. The problem here is that the logic in bug 1088915 looks for a very specific error code. That code is generated by a *compliant* server, but it seems like dreamhost aren't playing nice. :emk, do you think that you could expand the list of reasons for dropping back to weak ciphers to catch this?

Curiously, DreamHost's home page at https://www.dreamhost.com/ loads correctly (with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bits key, TLS 1.2).

DreamHost is in the progress of updating all their servers as far as I understand the situation (see http://www.dreamhoststatus.com/ under "Upgrading"), but they are taking rather long to get there. So depending on how fast they get there, this might get resolved in time. (They have not yet replied to me by the way.) whatwg.org is another case of a DreamHost server that is not updated, but curiously SSLv3 is not disabled there and it offering both TLSv10 and SSLv3 combined with RC4 does not seem to trigger an issue in Firefox Nightly.

(In reply to Martin Thomson [:mt] from comment #3) > Thanks for doing that Anne. This is probably a combination of bug 1088915 > AND bug 1084025. Though a compliant server will not trigger this behaviour. > The problem here is that the logic in bug 1088915 looks for a very specific > error code. That code is generated by a *compliant* server, but it seems > like dreamhost aren't playing nice. > > :emk, do you think that you could expand the list of reasons for dropping > back to weak ciphers to catch this? Bug 1084025 was unrelated (see bug 1088915 comment #36). I'm testing it locally and it looks like works. Patch is coming.

Honestly, I'm reluctant to add this. They should really stop needing RC4 cipher suites especially when they are going to drop SSL 3.0 support...

(In reply to Masatoshi Kimura [:emk] from comment #7) > Honestly, I'm reluctant to add this. They should really stop needing RC4 > cipher suites especially when they are going to drop SSL 3.0 support... Yep. It's not great. But it's not practical to unilaterally turn the security up to the maximum. If that were the case, we'd be reduced to using 4096-bit ff-DHE and maybe ECDHE with SHA-256 certificates and AES-GCM on TLS 1.2 only. Of course, we could only talk to a handful of sites then. Then we would lose relevance because our users would just switch to our competitors. As it stands, I think that we can strike a balance. If people want a tougher browser, maybe we can ship a "paranoid version" extension for them that disables all of the bad stuff.

We should start logging warnings to the console, e.g. bug 1092835 & co. And we should probably also actively measure usage. That will pave some path towards getting developers more informed about this going forward and making it easier to remove bad features.

(In reply to Martin Thomson [:mt] from comment #9) > Yep. It's not great. But it's not practical to unilaterally turn the > security up to the maximum. I agree in general. But in this specific case, they break compatibility and kill WinXP/IE6 users without adding any security benefits. They don't allow CBC mode block ciphers anyway. > If that were the case, we'd be reduced to using > 4096-bit ff-DHE and maybe ECDHE with SHA-256 certificates and AES-GCM on TLS > 1.2 only. As an aside, we should support at least two methods in case the algorithm has a vulnerability or an NSA backdoor.

If you believe the research, AES-GCM is the only mode not broken or weakened somehow (see RFC 7366). They aren't *completely* broken, but that's not the point. We don't do this because we accept that some security for a large group is better than really good security for a vastly reduced group. And yes, I take your point about vulnerability: currently we have only finite field DH if ECDH proves to be somehow bad. But we're working on that (or the CFRG are) and we should have new curves (in a twisted Edwards form, no less) relatively soon.

So far DreamHost told me that someone specific is looking into it and that therefore it might take a little longer to get a response. However, per https://www.ssllabs.com/ssltest/analyze.html?d=panel.dreamhost.com they are now offering more than RC4 and can therefore be accessed again. Not quite the upgrade we are looking for, but it works.

Comment on attachment 8516641 [details] [diff] [review] Deal with "cipher mismatch intolerant" servers Transferred to bug 1092998.

Did anyone ask DreamHost which kind of SSL server they were using on panel.dreamhost.com when only the RC4 cipher suites was enabled?