You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Kaspar Brand <ht...@velox.ch> on 2014/11/01 08:15:02 UTC
Re: Older clients stopped working after server disabled SSLv3
On 29.10.2014 16:42, Yann Ylavic wrote:
> On Wed, Oct 29, 2014 at 2:52 PM, Mikhail T. <mi...@aldan.algebra.com> wrote:
>> That would solve our problem, though some may wonder about the subtle
>> differences between "any" and "all" :-) More seriously, it would also make
>> the config-files incompatible with earlier httpd-releases -- whereas the
>> patch I linked to does not have this problem.
Definitely agreeing with Mikhail. Adding "Any" as another option is just
likely to cause even more confusion (and I'm also not in support of adding
things like "safe", just for the records).
Without clear steps on how to reproduce the problem (what httpd version,
what OpenSSL version, what client, what SSLProtocol settings), I'm fairly
doubtful that there really is a problem here. From a quick glance at
OpenSSL's s23_srvr.c:ssl23_get_client_hello(), I fail to see any reason
why the current mod_ssl code in
ssl_engine_init.c:ssl_init_ctx_protocol() would disable the acceptance
of an SSLv2 compatible ClientHello when a single protocol setting (cases
like protocol == SSL_PROTOCOL_TLSV1) is active.
Reading further down on the serverfault entry referenced earlier [1],
the "real" OP (Matt Hughes, i.e. the one who posted to httpd-users, in
the thread mentioned by Jeff) meanwhile came to the conclusion that his
problem "was a non-issue all along. Apache will accept SSLv2 handshake
with either of the configurations I posted above". In fact, I have no
problem to connect to httpd/mod_ssl with "SSLProtocol TLSv1", when
using "openssl s_client -cipher RC4-MD5 -connect ...", (provided that
RC4-MD5 is still enabled server-side). In that case, I'm seeing an
SSLv2 compatible hello, with TLS 1.0 getting negotiated in the end.
Kaspar
[1] http://serverfault.com/questions/637880/disabling-sslv3-but-still-supporting-sslv2hello-in-apache/
Re: Older clients stopped working after server disabled SSLv3
Posted by Kaspar Brand <ht...@velox.ch>.
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
Re: Older clients stopped working after server disabled SSLv3
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Nov 1, 2014 at 1:04 PM, Kaspar Brand <ht...@velox.ch> wrote:
> On 01.11.2014 11:23, Yann Ylavic wrote:
>> The real questions IMO is:
>> Is SSLv2Hello replied with TLSv1.x server hello really safe against
>> MITM/poodle/other attacks?
>
> Well, no one can answer this question with "yes" as long as you do not
> define "other attacks". From what is known today, however, accepting
> SSLv2 client hellos does not lead to additional vulnerabilities compared
> to a TLS client hello.
OK, thanks for clarifying this, no (known) issue then from a server perspective.
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.
> See also RFC 6176 section 3:
>
>> o TLS servers MAY continue to accept ClientHello messages in the
>> version 2 CLIENT-HELLO format as specified in RFC 5246 [TLS1.2],
>> Appendix E.2. Note that this does not contradict the prohibition
>> against actually negotiating the use of SSL 2.0.
>
> And this is what RFC 5246 says about its interpretation:
>
>> For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
>> way as a ClientHello with a "null" compression method and no
>> extensions.
>
> (Less options and extensions usually mean less potential for getting
> things wrong - just a general observation, not specific to the issue at
> hand.)
I guess it depends on whether or not extensions are involved in the
counter measures.
>
>> The problem is that with OpenSSL 0.9.8, "ALL -SSLv3" leaves only
>> SSL_PROTOCOL_TLSV1, and TLSv1_server_method() won't accept SSLv2Hello
>> (according to my own tests with openssl s_client).
>
> Ok, I see - so it's actually not about "Older clients" (as the subject
> of this thread refers to), but about mod_ssl compiled against OpenSSL
> 0.9.8 and not allowing TLS 1.0 connections with an SSLv2 compatible
> hello, is that correct?
Yes, at least for my own tests.
But is openssl-1.x's TLSv1_server_method() acting differently than
0.9.8's one with regard to SSLv2Hello?
(I'll give it a test).
> Given that 1.0.0 has been around for more than 4
> years already and 0.9.8 will be EOL'ed by the end of 2015, I don't think
> we should spend too much effort into addressing such legacy-version
> issues. I would again point to RFC 6176 section 3, and specifically:
>
>> o TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-
>> HELLO message format. Clients MUST NOT send any ClientHello
>> message that specifies a protocol version less than
>> { 0x03, 0x00 }. As previously stated by the definitions of all
>> previous versions of TLS, the client SHOULD specify the highest
>> protocol version it supports.
>
> (i.e., there's no good reason for a TLS-capable client to use an SSLv2
> compatible hello.)
Well, end of 2015 is not quite the same as tomorrow...
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...
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".
>
>> openssl s_client (with no protocol option, eg. -tls1/-ssl3/...) uses SSLv2Hello.
>
> It's not just determined by the use of these protocol switches,
> actually. It also depends on the OpenSSL version and whether SSLv2
> ciphers are still enabled. With OpenSSL 1.0.0 and later, SSLv2
> compatible client hellos are essentially gone:
So it might also depend on "Older" vs "Newer" clients too...
Regards,
Yann.
Re: Older clients stopped working after server disabled SSLv3
Posted by Kaspar Brand <ht...@velox.ch>.
On 01.11.2014 11:23, Yann Ylavic wrote:
> How about SSLv2Hello keyword (à la JDK), should we agree on a real
> issue caused by "ALL -SSLv3" (see below)?
This keyword wouldn't fit into the current set of options, so I'm not in
favor of it (the SSL2 compatible hello is like a flag which is
orthogonal to the protocol version).
> The real questions IMO is:
> Is SSLv2Hello replied with TLSv1.x server hello really safe against
> MITM/poodle/other attacks?
Well, no one can answer this question with "yes" as long as you do not
define "other attacks". From what is known today, however, accepting
SSLv2 client hellos does not lead to additional vulnerabilities compared
to a TLS client hello. See also RFC 6176 section 3:
> o TLS servers MAY continue to accept ClientHello messages in the
> version 2 CLIENT-HELLO format as specified in RFC 5246 [TLS1.2],
> Appendix E.2. Note that this does not contradict the prohibition
> against actually negotiating the use of SSL 2.0.
And this is what RFC 5246 says about its interpretation:
> For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
> way as a ClientHello with a "null" compression method and no
> extensions.
(Less options and extensions usually mean less potential for getting
things wrong - just a general observation, not specific to the issue at
hand.)
> The problem is that with OpenSSL 0.9.8, "ALL -SSLv3" leaves only
> SSL_PROTOCOL_TLSV1, and TLSv1_server_method() won't accept SSLv2Hello
> (according to my own tests with openssl s_client).
Ok, I see - so it's actually not about "Older clients" (as the subject
of this thread refers to), but about mod_ssl compiled against OpenSSL
0.9.8 and not allowing TLS 1.0 connections with an SSLv2 compatible
hello, is that correct? Given that 1.0.0 has been around for more than 4
years already and 0.9.8 will be EOL'ed by the end of 2015, I don't think
we should spend too much effort into addressing such legacy-version
issues. I would again point to RFC 6176 section 3, and specifically:
> o TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-
> HELLO message format. Clients MUST NOT send any ClientHello
> message that specifies a protocol version less than
> { 0x03, 0x00 }. As previously stated by the definitions of all
> previous versions of TLS, the client SHOULD specify the highest
> protocol version it supports.
(i.e., there's no good reason for a TLS-capable client to use an SSLv2
compatible hello.)
> openssl s_client (with no protocol option, eg. -tls1/-ssl3/...) uses SSLv2Hello.
It's not just determined by the use of these protocol switches,
actually. It also depends on the OpenSSL version and whether SSLv2
ciphers are still enabled. With OpenSSL 1.0.0 and later, SSLv2
compatible client hellos are essentially gone:
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9ae5743515f88f481c0e1075c21404e67d9cc197
Kaspar
Re: Older clients stopped working after server disabled SSLv3
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Nov 1, 2014 at 8:15 AM, Kaspar Brand <ht...@velox.ch> wrote:
> On 29.10.2014 16:42, Yann Ylavic wrote:
>> On Wed, Oct 29, 2014 at 2:52 PM, Mikhail T. <mi...@aldan.algebra.com> wrote:
>>> That would solve our problem, though some may wonder about the subtle
>>> differences between "any" and "all" :-) More seriously, it would also make
>>> the config-files incompatible with earlier httpd-releases -- whereas the
>>> patch I linked to does not have this problem.
>
> Definitely agreeing with Mikhail. Adding "Any" as another option is just
> likely to cause even more confusion (and I'm also not in support of adding
> things like "safe", just for the records).
Well, I must admit ANY may be confusing (but definitively not a
compatibility issue).
How about SSLv2Hello keyword (à la JDK), should we agree on a real
issue caused by "ALL -SSLv3" (see below)?
This might also be confusing though, one may think this is the whole
SSLv2 protocol...
The real questions IMO is:
Is SSLv2Hello replied with TLSv1.x server hello really safe against
MITM/poodle/other attacks?
IOW, is it safe to accept SSLv2Hello whereas SSLv2 and SSLv3 are disabled?
I couldn't find any pointer to this answer, only conjectures about not
being treated unsafe by poodle vulnerabilty (online) detectors...
Clearly, is it worth handling it?
>
> Without clear steps on how to reproduce the problem (what httpd version,
> what OpenSSL version, what client, what SSLProtocol settings), I'm fairly
> doubtful that there really is a problem here. From a quick glance at
> OpenSSL's s23_srvr.c:ssl23_get_client_hello(), I fail to see any reason
> why the current mod_ssl code in
> ssl_engine_init.c:ssl_init_ctx_protocol() would disable the acceptance
> of an SSLv2 compatible ClientHello when a single protocol setting (cases
> like protocol == SSL_PROTOCOL_TLSV1) is active.
I also posted a reproducer in this thread...
The problem is that with OpenSSL 0.9.8, "ALL -SSLv3" leaves only
SSL_PROTOCOL_TLSV1, and TLSv1_server_method() won't accept SSLv2Hello
(according to my own tests with openssl s_client).
With OpenSSL 1.x, all SSL_PROTOCOL_TLSV1* are still active, and httpd
will use SSLv23_server_method(), hence SSLv2Hello is accepted.
>
> Reading further down on the serverfault entry referenced earlier [1],
> the "real" OP (Matt Hughes, i.e. the one who posted to httpd-users, in
> the thread mentioned by Jeff) meanwhile came to the conclusion that his
> problem "was a non-issue all along. Apache will accept SSLv2 handshake
> with either of the configurations I posted above". In fact, I have no
> problem to connect to httpd/mod_ssl with "SSLProtocol TLSv1", when
> using "openssl s_client -cipher RC4-MD5 -connect ...", (provided that
> RC4-MD5 is still enabled server-side). In that case, I'm seeing an
> SSLv2 compatible hello, with TLS 1.0 getting negotiated in the end.
openssl s_client (with no protocol option, eg. -tls1/-ssl3/...) uses SSLv2Hello.
The serverfault's OP does not mention the version of openssl used by his httpd.
Regards,
Yann.