User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.19) Gecko/20110430 Iceweasel/3.5.19 (like Firefox/3.5.19) Build Identifier: We recently tried to disable SSLv2 support on https://www.eff.org. We started to receive a steady stream of bug reports from users unable to access the site. After investigation, it turned out that these users were running modern Firefoxes, but they had somehow managed to uncheck the "support TLS" and "support SSLv3" settings. It would be much more helpful if all modern clients supported a secure version of HTTPS, and if there was a way for security-conscious users to disable insecure versions of it. Reproducible: Always

SSLv2 is already disabled, there's no UI to enable it anymore (but setting security.enable_ssl2 in about:config still works). I agree that some users might try to disable SSLv3 instead (thinking it's the same as SSLv2). But that's no reason to provide them with an easy way to enable SSLv2 again ... Note that if both TLS and SSLv3 are disabled, you can't connect with HTTPS at all. Maybe there should be a warning if you try to do that ?

Given that we have TLS 1.0 -> SSL 3.0 fallback already implemented in PSM as the default behavior, I propose the following: 1. Ignore (remove) the security.enable_tls preference. (In the future, when we implement TLS 1.1 or TLS 1.2, it may come back as security_enable_tls_1_0.) 2. Remove the entire "Protocols" section of Options -> Advanced -> Encryption. 3. permanently disable SSL 2.0 as per bug 593077. Note that we must continue to support the security.enable_ssl3 pref, as it is used by some organizations to disable SSL 3.0 support in favor of using TLS 1.0+ only.

If I understand correctly, the origin of this bug report is: "Some users play with prefs, they disable stuff they don't understand, and shoot themselves in the foot." We shouldn't try hard to prevent that, because in the end we would end up with a computer not having any buttons to click. Users (or a playing child) can make lots of other changes that will have equal results. For example, someone could click "enable "proxy" (with nonworking settings), and in the next minute they can't connect to any sites at all. Let's distinguish between hidden prefs (that most users won't touch), and prefs exposed in the user interface. If we ever decided that we wanted to remove some of the prefs exposed in the user interface, I'd argue, let's still keep the underlying pref. So, please let's keep the security.enable_tls preference pref. It's described in the user interface as TLS 1.0 Some day we will have TLS 1.1 or TLS 1.2, and some people will suggest there must be a way to disable TLS 1.0. So, please keep the existing prefs for the sake of this. Having said all of this, in my understanding, the following is the proposal of this bug report: "Don't allow users to modify the most recent, most secure version of our crypto protocols". Which could mean, to hide the TLS 1.0 pref (as long as that is the most recent version we support. But I disagree. In my opinion this proposal is WONTFIX. Maybe tomorrow someone will detect a serious backdoor in TLS 1.0, so that SSL 3 will be actually considered to be safer? Who knows? Maybe we'll have to recommend to people to disable TLS 1.0? Maybe that seems unrealistic, but I don't know hoch much unrealistic or realistic it is. In any way, that's the idea of the pref. Trying to be more constructive: If you want to enhance the behaviour of Firefox, I'd propose, let's keep all choices, but give more information to the user. I can think of two ways to improve it: (a) if the user attempts to disable both prefs, essentially the user disables all SSL protocols, then show a warning, in some form. For example, that pref dialog could display a big red warning saying "you will not be able to connect to any secure sites". Please enable at least one security protocol. (b) If a user attempts to connect to a secure site, let's give a better error message. Instead of giving obscure error codes, let's clearly tell the user that it appears the user has explicitly disabled all secure protocols, and give the user an easy way to fix that, reeanble the protocols.

(In reply to comment #3) > (a) if the user attempts to disable both prefs, essentially the user > disables all SSL protocols, then show a warning, in some form. > > For example, that pref dialog could display a big red warning saying "you > will not be able to connect to any secure sites". Please enable at least one > security protocol. It's more subtle and nastier than that. Right now, if the user unchecks everything, it's not that they can't use HTTPS. Instead, they always use insecure SSLv2. They can still access HTTPS websites, *except* unusual websites like www.eff.org that have tried to retire protocol versions with known vulnerabilities (forget about hypothetical vulns in TLS 1.0!) For the population of users with insecure and broken settings in the profiles, it's also not going to help to move these setting variables out of the UI and into about:config, unless you simultaneously reset the variable to default. I guess this is a roundabout way of saying that I strongly agree with Brian Smith.

(In reply to comment #4) > It's more subtle and nastier than that. Right now, if the user unchecks > everything, it's not that they can't use HTTPS. Instead, they always use > insecure SSLv2. They can still access HTTPS websites, *except* unusual > websites like www.eff.org that have tried to retire protocol versions with > known vulnerabilities (forget about hypothetical vulns in TLS 1.0!) That's not what I'm seeing in Firefox 4.0 - I can't access any https site at all without SSLv3 and/or TLS (error ssl_error_ssl_disabled). That's also the reason why the EFF got the complaints in comment 0. Could it be that you still have security.enable_ssl2 set to true, even though the default has been false for a long time ? You're still using a very old version of IceWeasel : 3.5.19.

I also think, if a user disables SSL 3 and disables TLS 1.0, I'd assume they can't connect to any secure sites. I agree, only users who have explicitly enabled SSL 2 would still be able to connect to some sites. And if a user has really enabled SSL 2, and disabled the new things, there must have been a reason, and we should respect that. I think it's a very good idea to give better error messages and remind the user what's going on (stuff disabled, silly config), but I disagree with automatically overriding user configuration.

If your main worry were around SSLv2, we could stop supporting the security.enable_ssl2 pref. Firefox .next could disable SSLv2, hardcoded, and never look at the old ssl2 pref.

I have verified this. I did the following: - used ancient Firefox 1.5 to create a new profile - disabled SSL 3, disabled TLS 1.0 - I kept SSL 2 enabled (the old default) - quit. Start Firefox 3.6 with that profile - look at about:config, search for security.enable I see that SSL 2 is now disabled (the new default). SSL 3 and TLS 1.0 are still disabled If I try to any SSL site, I get an error message: "can't connect security, because the SSL protocol is disabled". I conclude, the only scenario where a user can end up with - modern Firefox - SSL 2 enabled - SSL 3 disabled, TLS 1.0 disabled is when a user used a version of Firefox that had SSL 2 disabled by default, but a user had explicitly decided to reenable it.

With my new proposal, from comment 7, = stop honoring the SSL 2 pref such users (from comment 8) = who had previously explicitly enabled SSL 2 = and disabled SSL3/TLS1 would no longer be able to connect anywhere, but would the error message "can't connect security, because the SSL protocol is disabled" Now, if you want to make it easier for users to reenable SSL3/TLS, all you have to do is to implement an better error page for this, and add a button that says "reenable modern SSL protocols" I believe this would be quite simple to implement. No research needed. We already know how to add buttons to an error page, see the error page for bad certs.

Based on what I've read in this bug, this is more about communicating expected behaviour to our users than being a "bug" in our security HTTPS/SSL code. Moving to ENHANCEMENTS. Please revert this change if you think that is in error.

(In reply to comment #5) > > That's not what I'm seeing in Firefox 4.0 - I can't access any https site at > all without SSLv3 and/or TLS (error ssl_error_ssl_disabled). That's also the > reason why the EFF got the complaints in comment 0. > > Could it be that you still have security.enable_ssl2 set to true, even > though the default has been false for a long time ? You're still using a > very old version of IceWeasel : 3.5.19. Well it's the latest Firefox in Debian unstable, but yes ;). As Kai's research has shown, there could be fairly obscure profile-history-dependencies involved here. I can not currently reproduce the bug, although I have a .pcap recording of a debian unstable seamonkey (iceape) sending an SSLv2 handshake on the 30th of March this year. here has only been one update to iceape since then: http://packages.debian.org/changelogs/pool/main/i/iceape/iceape_2.0.14-1/changelog (which doesn't *look* like it should have changed anything)

Attaching a copy of the pcap. At this point I really am not sure what caused this -- downgrading to iceape 2.0.13 didn't cause it to reappear.

> Well it's the latest Firefox in Debian unstable That's incredibly depressing. :(

Digging further, I collected a lot of my browsers' port 443 traffic, and there are in fact a few other places where wireshark shows SSLv2 Client Hello messages being sent. However, I think these are actually SSLv3 handshakes that wireshark misreports as SSLv2 because the record layer is v2 (!). So, I think this can be closed as a bug; perhaps we should open a new enhancement request for Kai's suggestion that the HTTPS disabled error message be friendlier.

Actually, based on comment 14, this sounds more like INVALID (ie. not a Firefox bug). FIXED is only used in cases where something was checked in to resolve the issue. Thanks for following up though.

This is still a valid bug in that it doesn't make sense to let the user disable all versions of SSL/TLS. I do agree with Kai that it isn't a high priority.

This looks like a dup, that has just been fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=733632

Users cannot disable all versions of TLS anymore. The UI has been removed, and even if the user sets nonsensical values for the prefs, the logic that interprets the prefs will use the default configuration (SSL 3.0 and higher). Also, this was fixed for existing users because the old prefs tied to the old checkboxes are now ignored and everybody got set to having SSL 3.0 and later enabled by default.