httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <>
Subject Re: Older clients stopped working after server disabled SSLv3
Date Sun, 02 Nov 2014 09:47:51 GMT
On 01.11.2014 14:46, Yann Ylavic wrote:
> There is still that a client handshaking with a SSLv2Hello (by using
> SSLv23_client_method()) is likely to accept SSLv[23] protocols (unless
> using SSL_OP_NO_SSLv[23] explicitly like today's mod_ssl, but it's
> probably not the case for legacy clients), so MITM attacks on SSLv2
> for example might still be possible.

Protecting broken clients from MITM attacks is not within mod_ssl's
power (nor is it really its business)... the only thing we can do server
side is to refuse negotiating a protocol version lower than TLS 1.0.

The "badness" of SSLv3 as a consequence of Poodle is probably also
somewhat overstated, in particular when taking into account that TLS 1.0
isn't really immune to this kind of padding problem, see this thread:

> But is openssl-1.x's TLSv1_server_method() acting differently than
> 0.9.8's one with regard to SSLv2Hello?

No, it's the same in both versions. Meanwhile I found that there's
actually a subtle difference between 2.2 and 2.4: this change here (from
2005 already) -

was never backported to 2.2, but made its way into 2.4, with the
following impact on mod_ssl:

- when httpd/mod_ssl 2.2 is compiled/run with OpenSSL 0.9.8, "all -SSLv2
-SSLv3" does allow SSLv2 compatible client hellos

- when httpd/mod_ssl 2.4 is compiled/run with OpenSSL 0.9.8, "all
-SSLv3" does *not* allow SSLv2 compatible client hellos

In both cases, "all -SSLv2 -SSLv3" or "all -SSLv3" with OpenSSL 0.9.8
actually amount to "TLSv1", but due to the differences in the
ssl_engine_init.c:ssl_init_ctx_protocol() code between 2.2 and 2.4, the
resulting behavior isn't the same (as for 2.2, SSLv23_server_method() is
chosen, while for 2.4, it's TLSv1_server_method()). My test from
yesterday was with 2.2.29 compiled against OpenSSL 1.0.1, in which case
even setting "SSLProtocol TLSv1" won't reject SSLv2 compatible client

> The fact is that several today's clients (probably legacy/heavy) do
> support TLSv1 easily by using SSLv23_client_method() (and let the
> linked openssl do the right thing) since a while, and it's not always
> an option to modify these clients, and no option at all when you are a
> httpd admin...

All we currently know (from the message starting this thread) is

> we noticed, that curl itself and libcurl-using programs (such as git) stopped
> working on some of the (older) systems -- such as RHEL5 -- when invoked against
> the https-URLs pointing at the reconfigured servers.

so it's still quite unclear to me what specific issue we are trying to
address (and how common this is).

> Unless we consider/claim these clients are unsafe per se, and/or
> require openssl >= 1.0 for mod_ssl, I don't see why we should prevent
> them from connecting to httpd configured with "ALL -SSLv3".

IMO, it's more the question of how much tweaks we want to add to mod_ssl
to get OpenSSL behave with regard to supporting SSLv2 compatible client
hellos. If OpenSSL had an official API for enabling/disabling this
setting for the TLS 1.* protocols, then I would be more supportive of
this idea. If we have to rely on implicit OpenSSL behavior in the end,
then it feels more like a hack to me.


View raw message