On Sat, Nov 1, 2014 at 1:04 PM, Kaspar Brand <httpd-dev.2...@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.
