> From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm > Sent: Wednesday, May 28, 2014 13:04
> On 5/25/2014 2:22 PM, Hanno Böck wrote: > > Some clients (e.g. all common browsers) do fallbacks that in fact > > can invalidate all improvements of later tls versions. > > > > These fallbacks also can happen by accident (e.g. bad connections) and > > sometimes disable features like SNI. > > > > That's why I recommend to everyone that we need at least to deprecate > > SSLv3. > > > > > There is also the very real issue that a few platforms which no longer > receive feature updates (such as new TLS protocol versions) are stuck > at SSLv3. Permanently. So until those platforms become truly extinct, > a lot of servers need to cater to their continued existence by allowing > ancient TLS versions. > > At that point the problem is how to do the best defense against > man-in-the-middle downgrade-to-SSLv3 attacks. For instance is there a > way to > ensure that the server certificate validation done by an SSLv3 > (compatible) client will fail if both server and client were capable of > TLS v1.0, but a man in the middle tampered with the version negotiation? > I don't think you want it on the cert. The cert only asserts identity and ownership of the key, it isn't specific to the server implementation or features and making it so would I bet actually discourage people from upgrading to the latest and most complete protocol (not a benefit). And of course very few TLS connections use a client cert, so the server would almost never be able to detect/report the problem, even though a decent server operator would like to know about an attack targeted (substantially) at them and their users, and I'd bet is more likely to try to do something about it than most web users at least. The Finished exchange protects against *tampering* in a handshake, and has since SSLv3 (inclusive). The problem is clients that fall back at the application level if the (good) handshake is *blocked* (denied). Remember we had a fair number of "legit" cases of this when TLSv1.2 in 1.0.1 added numerous suites by default plus one extension and ClientHello growing beyond 256 broke some servers -- even though they claimed to implement specs that implicitly required it. In those cases it was actually reasonable for a client to fall back to 1.1. > Failing that, is this something that could be added to the TLS v1.3 > standard (i.e. some signed portion of the SSLv3 exchange being > unnaturally different if the parties could and should have negotiated > something better). > I see no reason to tie this to a TLSv1.3 document, when and if there is one. This is a proposed change to SSL, which is not TLS (only technically similar). The "prohibition" on SSLv2 is a standalone document: 6176, which updates 2246 4346 5246 to retroactively remove the SSLv2 compatibility. (Of course an IETF prohibition has no legal force and doesn't actually prevent or even deter people from continuing to use SSLv2, it just lets us wag our fingers at them.) Since SSLv3 was belatedly retroactively published as 6101, this could even be labelled as an update to that, FWIW. > Not remembering the SSLv3 spec details, one option could be to announce > support for a special "we also support TLS v1.0" cipher suite, which no > one can really implement (by definition), but whose presence in a > cipher suite list from the other end indicates that said other end > announced SSLv3.1 (TLS v1.0) support in an unsigned part of the > exchange. This could even be specified in an "UPDATE RFC" for the > existing TLS v1.0..v1.2 versions, and a CVE number assigned to the > common bug of its non-implementation (after library implementations > become available). > In other words like the Signaling CipherSuite Value (SCSV) used for 5746 Secure Renegotiation (aka the Apache bug) in cases where the extension didn't work (or might not work reliably). I'd say experience confirmed that worked well enough to be considered an option. But many users, especially web users, want to connect to the server even if it isn't "truly" secure. When we make it harder for https to work, they *will* use http instead, or else complain very loudly. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
