The latest telemetry from beta 31 shows that sslv3 connections are now only .265% of all connections. Seems it is finally time to disable SSL v3. % of ssl3 by version: beta 24: 1.32% beta 25: 0.79% beta 26: 0.54% beta 27: 0.39% beta 28: 0.31% beta 29: 0.30% beta 30: 0.32% beta 31: 0.26% Also the SSL pulse ( https://www.trustworthyinternet.org/ssl-pulse/ ) claims 99.3 % of sites support TLS 1.0

(In reply to Camilo Viecco (:cviecco) from comment #0) > The latest telemetry from beta 31 shows that sslv3 connections are now only > .265% of all connections. Seems it is finally time to disable SSL v3. > > Also the SSL pulse ( https://www.trustworthyinternet.org/ssl-pulse/ ) claims > 99.3 % of sites support TLS 1.0 What are the advantages of disabling SSL 3.0 completely over fixing bug 689814 instead? It seems like the risk:reward ratio is much higher for bug 689814. What problem are you trying to solve?

Comment on attachment 8461028 [details] [diff] [review] no-sslv3-desktop Review of attachment 8461028 [details] [diff] [review]: ----------------------------------------------------------------- Initial patch. Desktop only (if no screams we can increase to all products)

Comment on attachment 8461028 [details] [diff] [review] no-sslv3-desktop Review of attachment 8461028 [details] [diff] [review]: ----------------------------------------------------------------- Initial patch. Desktop only (if no screams we can increase to all products)

Camilo, please answer the questions from comment 1. I am excited about the idea of nuking SSLv3, but AFAICT there are other ways of solving the most serious SSLv3-related issues, and this causes compatibility risk. However, if the Firefox team is willing to accept the compatibility risk without doing those other things, I'm not going to argue against doing it.

I am trying to get rid of legacy crypto (crypto that no academics are currently looking at). While there are no known attacks against SSL v3, but we know there are weaknesses in its mac and key derivation and since no academics are looking this is a great opportunity for motivated attackers with crypto expertise. Solving 689814 would give better functionality, but is also a harder bug to solve. I think the goal of this is to try it on nightly and if nothing really breaks to make it ride the trains. Who do you think would object to this ?(there seems agreement on this being a good idea around my desk, but this is a self selecting security conscious group)

(In reply to Camilo Viecco (:cviecco) from comment #6) > I am trying to get rid of legacy crypto (crypto that no academics > are currently looking at). While there are no known attacks against > SSL v3, but we know there are weaknesses in its mac and key derivation and > since no academics are looking this is a great opportunity for motivated > attackers with crypto expertise. > > Solving 689814 would give better functionality, but is also > a harder bug to solve. Fixing bug 689814 is approximately the same amount of work as fixing this bug. > I think the goal of this is to try it on nightly and if nothing really breaks > to make it ride the trains. Who do you think would object to this ?(there > seems agreement on this being a good idea around my desk, but this > is a self selecting security conscious group) Let's make sure we all understand: Fixing this bug will solve some potential (but not yet demonstrated) issues. We think that this affects less than 1% of websites, according to our telemetry data and other measurements. However, it definitely means that some websites will stop working in Firefox. Bug 689814 proposes that we always tell the server that we accept at least TLS 1.0 or later, but will still allow us to talk SSLv3 with sites that choose it. Bug 689814 solves all the known problems we have with our SSLv3 support and is the minimum change we can do. This bug (1042811) proposes to go one step forward and completely drop compatibility with any site that only supports SSLv3, to guard against possible unknown vulnerabilities in the SSLv3 protocol. The argument is that nobody is going to publish an attack on SSLv3 because SSLv3 is no longer interesting to researchers. At or near the same time we're doing this, we're also going to be working on eliminating our acceptance of certificates signed with RSA keys less than 2048 bits. That will also break compatibility with some websites, but it is also something that is very important to do. Gavin and Justin: No matter what, we're going to need to make changes that break compatibility with a fraction of 1% of websites. How much effort should be spent on minimizing that breakage by tenths of one percent of websites? If you two are not concerned about the compatibility impact, then I'm not going to concern myself with it either.

This would presumably also deal with bug 450280 (if still applicable).

(In reply to Dave Garrett from comment #8) > This would presumably also deal with bug 450280 (if still applicable). Bug 450280 would be fixed by bug 689814. Literally, AFAICT, there is no known problem that this bug fixes; the advantage of fixing this bug over bug 689814 is that <1% of websites would be protected against as-of-yet-unknown problems by breaking compatibility with those websites.

(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #7) > Fixing this bug will solve some potential (but not yet demonstrated) issues. > We think that this affects less than 1% of websites, according to our > telemetry data and other measurements. Can you say more about what this data shows? What telemetry probes are involved? 1% would actually be a lot of sites. Do we know anything about the actual impact/usage of that <1% of sites? If this only broke a single site (facebook.com) that would nearly be 0%, but obviously not an acceptable change. :) But I think you're basically saying this will have an acceptably small impact relative to other similar things we've done. That seems fine if so, just making sure we actually understand the impact. That said, since this is just a pref-flip, it's easy to revert if we find it has disproportionate pain. (I'd probably recommend holding off on removing the underlying code until this hits release, though. Speaking of which, would this be something more likely to impact ESR (enterprise) users?)

(In reply to Justin Dolske [:Dolske] from comment #10) > (In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) > from comment #7) > > > Fixing this bug will solve some potential (but not yet demonstrated) issues. > > We think that this affects less than 1% of websites, according to our > > telemetry data and other measurements. > > Can you say more about what this data shows? What telemetry probes are > involved? The telemetry probe is SSL_HANDSHAKE_VERSION: http://telemetry.mozilla.org/#filter=release%2F30%2FSSL_HANDSHAKE_VERSION > 1% would actually be a lot of sites. Do we know anything about the actual > impact/usage of that <1% of sites? If this only broke a single site > (facebook.com) that would nearly be 0%, but obviously not an acceptable > change. :) The telemetry probe measures which SSL handshakes negotiate which version. So, according to the telemetry probe, 25/1000 connections made by Firefox use SSL 3.0. > But I think you're basically saying this will have an acceptably small > impact relative to other similar things we've done. That seems fine if so, > just making sure we actually understand the impact. No, I am saying that, because we are making so many compatibility-breaking changes, the negative compatibility impact of each one should be minimized so they don't add up to a huge breakage. 25/1000 connections is already huge, IMO. But others disagree that that is huge. > Speaking of which, > would this be something more likely to impact ESR (enterprise) users?) This is something that is likely to impact ESR users in ways that we cannot measure because many ESR users don't report telemetry due to it being disabled by system administrators site-wide, IIUC telemetry reporting configuration trends.

(In reply to Justin Dolske [:Dolske] from comment #10) > would this be something more likely to impact ESR (enterprise) users?) It doesn't really affect ESR users yet, though. Firefox 31 ESR will continue to have SSL3 on by default and should it be off by default for the next ESR they could simply re-enable it if really needed. I don't think anyone is suggesting removing all capability quite yet.

Comment on attachment 8461028 [details] [diff] [review] no-sslv3-desktop When you change the default value of a pref in a *.js file, you also need to change the default value of the pref within the C++ source file (in nsNSSComponent.cpp in this case) that is used when the value from the *.js file is inaccessible for some reason (probably never, but possibly due to file permission stuff maybe). If you submit a new patch, please ask a different person to review it, as I don't have time to work on the fallout of this.

I am not seeing a very strong argument for starting here rather than with bug 689814. It sounds like we will want to fix this bug eventually, but given compatibility concerns it makes sense to progress gradually rather than shooting for the moon.

All the eyes and action are bug 1076983, so I'm going to mark this one as a duplicate.