On 5/30/2014 12:03 AM, Dave Thompson wrote:
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.
Sorry for the sloppy wording, I obviously meant the certificate powered
validation of the handshake, not the certificate attributes.
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.
Indeed, that is why such TLSvX.Y SCSVs need to be carefully designed to
specify what each one claims other than simply "every (obscure or not)
aspect of some very long spec, which might have common misimplementations".
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
