689814 - Disable insecure TLS version fallback to SSL 3.0 by default

Status: RESOLVED DUPLICATE of bug 1083058

(Core :: Security: PSM, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ This bug was initially created as a clone of Bug #689813 +++

I would like to coordinate with other browser vendors to disable our insecure fallback to SSL 3.0 when we cannot connect to a server and/or we detect some SSL errors. Bug 689813 is about implementing a pref to control this. This bug is about changing the default to be secure (i.e. to not do the fallback).

Comment 1

[Florian Bender]

Bug 901718 aims to remove the fallback.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I suggest the following plan of attack:

1. Fix bug 901718 (remove the fallback for connection resets and EOF to match Chrome).
2. Fix bug 707275 (add telemetry to measure this stuff).
3. Scan port 443 of the public IPv4 address space to find intolerant servers that support SSL 3.0, and build a blacklist of hostnames by extracting CN and subjectAltName from the certs returned in the SSL 3.0 handshake's Certificate message, truncating to eTLD+1. (For example, foo.example.com, bar.example.com, 
4. Restrict insecure fallback for port 443 to SSL 3.0 to non-public IPv4 address space and/or the blacklist we've built, and let this go to release channel. This should get the attention of people using TLS-intolerant products if/when they add new publicly-accessible hosts.
5. Disable SSL 3.0 fallback for non-public IPv4 address space, and let this ride the trains (i.e. ship two releases between #4 and #5).
6. Declare success.
7. File a bug about doing the same for ports other than 443 and/or do analogous things for Thunderbird.
8. Periodically prune the blacklist.

According to some rather old (2011) numbers from Yngve, there were about 600,000 publicly-visible TLS servers in his study, and about 1.75% of them had some kind of version intolerance. I suspect the number of publicly available sites has decreased since then, and I'll estimate that coalescing by eTLD+1 should reduce the number by 1/3. So that means the blacklist would need to be 600,000 * 0.0175 * 0.66 = 7,000 entries long. Assume every eTLD+1 is about 25 bytes: that's 175KB. I would be very surprised if we couldn't compress that down to less a lot less than 100KB. Since TLS 1.0 intolerance fallback doesn't have to be fast (it's already doing a huge number of network round trips just to get to TLS 1.0 -> SSL 3.0), we can read and decompress the data on the fly for each handshake, optimizing for minimum memory consumption.

It seems there are intermediaries that we have to tolerate that already force TLS 1.2 -> TLS 1.1 -> TLS 1.0 fallback, so preventing fallback to SSL 3.0 may be the best we can do. But, I have some ideas for how to make the version we send in our ClientHello irrelevant; we should work on that as part of the TLS 1.3 effort at IETF. But, even just preventing fallback to SSL 3.0 enables us to say we'll always send extensions (including, in particular, SNI, NPN, and supported_curves), which is a win.

Comment 4

[Devdatta Akhawe [:devd]]

I have a question on how we will capture data to help identify whether we can turn off SSLv3 support. If I am not wrong, we can only measure how many https connections used SSLv3. But, how that impacts end user experience can't be seen. For example, are those ssl-only resources secondary resources (imgs, iframes) only? Do they make the site unusable? Are they internal network only? These issues seem similar to the mixed-content telemetry issues.

I am also not sure about having a blacklist. For example, should we add citibank.com to the blacklist? Or is it better that we encourage them to support TLS?

See https://www.ssllabs.com/ssltest/analyze.html?d=citibank.com&s=192.193.219.58

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

s/blacklist/whitelist/ in comment 3.

Dev, this is not about disable SSL 3.0 completely. It is only about disabling the INSECURE fallback to SSL 3.0. In the SSL Labs report you linked to, this is (partially) captured the lines "TLS extension intolerance" and "TLS version intolerance". When either/both of those are "yes" then this bug is relevant; when both are "no" (as in the case of citibank.com) then this bug is not relevant.

The TLS protocol provides a way to "securely" negotiate down to an older version, and if a site uses that mechanism (like citibank.com apparently does) then it would be unaffected by this change. This is "secure" because the integrity of the handshake is verified by the Finished messages in the handshake. I put "securely" and "secure" in quotes because, in theory, there may be some weakness in the SSL 3.0 PRF or some cipher suite that may make it possible for a MitM to forge a "secure" downgrade. However, we currently do not know of any such attacks. Regardless, it isn't necessary for an attacker to employ any such advanced attacks right now since they can just send unauthenticated data to us to force us to do our current insecure fallback.

Comment 6

[Devdatta Akhawe [:devd]]

Sorry, my mistake. Thanks for the clarification!

Comment 7

[Martin Thomson [:mt:]]

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=d4397b592d98

Comment 8

[Martin Thomson [:mt:]]

Looks like we have a more serious reason to do this.  I'm going to mark this as a duplicate, since all the eyes are on bug 1076983.

Comment 9

[Martin Thomson [:mt:]]

And now I've confusing bug numbers.  Apologies for the spam.

Comment 10

[Masatoshi Kimura [:emk]]

Bug 1083058 will fix this.