On 5/25/2014 2:22 PM, Hanno Böck wrote:
On Fri, 23 May 2014 16:32:15 +0000
Viktor Dukhovni <openssl-us...@dukhovni.org> wrote:
On Fri, May 23, 2014 at 06:11:05PM +0200, nicolas....@free.fr wrote:
use at the very least TLSv1 (and preferably TLSv1_2) protocol if
you want to use SSLv23_server_method(), don't forget to disable
SSLv2 and 3 protocols (and maybe TLSv1) with the command
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3);
Typically, leaving SSLv3 enabled is just fine if both ends support
something stronger they'll negotiate that.
That's not always true.
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?
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).
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).
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
