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: https://www.ietf.org/mail-archive/web/tls/current/msg14058.html > 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) - https://svn.apache.org/viewvc?view=revision&revision=r264621 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 hellos. > 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. Kaspar
