Closed Bug 1123967 Opened 9 years ago Closed 9 years ago

Firefox thinks we still accept SSLv3

Categories

(Firefox :: Untriaged, defect)

3.5 Branch
x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1109859

People

(Reporter: erafaloff, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36

Steps to reproduce:

I have not been able to reproduce this issue personally, but our support team has received numerous reports about this issue from members of our website.

Go to fetlife dot com (NSFW).


Actual results:

Sporadically, a warning about SSLv3 will be displayed. I say "sporadically" because many members report this issue only happening sometimes.


Expected results:

We've long since disabled support for the SSLv3 protocol and recently reissued our certificate with SHA2 signing. We currently offer TLSv1.0 and a number of secure ciphers. I cannot figure out why Firefox insists that we are still supporting SSLv3.
Thank you for the cautiously worded but detailed bugreport!

Up until Firefox 36 (current beta), we're relying on an NSS error called no_cypher_overlap to detect sslv3 issues on the frontend. This error can have other causes, particularly if there are (as you might guess from the message) no ciphers supported by both Firefox and the webserver. Unfortunately because of the separation of backend and frontend code, our frontend doesn't have access to more detailed info about why the SSL connection failed, until such information was exposed in a patch to NSS, which only landed for Firefox 37. So this explains why people see this error despite you having (hopefully) very definitely disabled that everywhere. I'm sorry for unjust but angry/concerned letters/email you might be getting as a result - we figured that understandable errors rather than the obscure "no matching cyphers" errors would lead to more websites being fixed. :-(

Now, as to what you might do so users don't see any errors:

I'm assuming you're using a CDN and/or load balancers and not just a single server. The best I can suggest is checking which of those servers support which ciphers, and ensuring they're all on par. There being some discrepancy is my best explanation (without more info - heck, maybe people are behind proxies and those are muddling with things, so there are other possible explanations) for why people have this happen sometimes but not all the time.

For the users that are affected, they could try Firefox Developer Edition (37 right now) which has a more specific error message, but they might find that a bit too scary/unstable for their taste - and they'll still be seeing errors.

Now, why are some people having issues and others not: affected users should check their prefs in about:config and restore any security.ssl3.<whatever> preferences to their default value (no, these prefs are not just for "SSLv3", they're a little confusingly named).

Anyway, yes, people/add-ons/malware/whatever mess with them. Yes, it causes issues because we do then enable/disable those ciphersuites as instructed, and that does cause SSL connection failures. Latest gloriously messed up example: bug 1121706. Only discovered after we released Firefox 35, because few people alter these, but enough to get us multiple reports. Motivations by users to mess with these preferences include "I simply don't trust the elliptic curves of NIST" and "To force firefox to only use ciphers with AES 256 bits keys." and "I have no idea why this is not the default". YMMV. But asking affected users to check won't hurt.

As it is, this was reported before, so I'm going to mark this as a duplicate of the earlier bug. Please feel free to ping me here for followup questions/concerns, though.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
(In reply to :Gijs Kruitbosch from comment #1)
> Thank you for the cautiously worded but detailed bugreport!
> 
> Up until Firefox 36 (current beta)

Full disclosure: I still need to get the patch for 36 (bug 1098371) uplifted there (just asked for approval). Gavin, given this + dupe, we could alternatively not do that and go for one cycle without the specific feedback (but with fewer sad websites with wrongful error messages) until we get the correct error in 37. Or we can try asking the NSS folks again if it's possible to uplift/cherrypick the more specific error to 36. Thoughts?
Flags: needinfo?(gavin.sharp)
Talked this over with gavin. We're not going to land this error messaging in 36 unless we get the better error codes from NSS.
Flags: needinfo?(gavin.sharp)
Apologies for blundering into technical discussion with what might be a coincidence, but I just noticed this on a hotel wifi, where the reason seems to be linked to TalkTalk HomeSafe website-blocking.  

Connection via https in Firefox gives "Unable to Connect Securely // Firefox cannot guarantee the safety of your data on fetlife.com because it uses SSLv3, a broken security protocol. //  Advanced info: ssl_error_no_cypher_overlap"

Connection via https in Chrome gives "This webpage is not available"

Connection via http give TalkTalk's "Your HomeSafe settings prevent access to this site.".
You need to log in before you can comment on or make changes to this bug.