Is it safe to enable SSLv2 ClientHello support?

Question

In the wake of the POODLE attack, many web sites have dropped support for SSLv3. But some clients still in relatively common use as of May 2015 still initiate the handshake with an SSLv2 ClientHello message. For example, openssl 0.9.8 which ships with Mac OS X 10.10, and Java 6 which is also still in common use at least on Mac OS X.

Oracle recommends that servers using the JSSE to terminate SSL keep the SSLv2Hello pseudo-protocol enabled, which in turn allows an SSLv2 ClientHello handshake, for backward compatibility with such clients. (See table rows "Developers using JSSE APIs - Server").

Although clients using SSLv2 ClientHello are vulnerable to protocol downgrade attacks, this is also true of clients using later handshake versions as well, unless both the client and the server support TLS_FALLBACK_SCSV. And as long as the server has disabled SSLv2 and SSLv3, the handshake cannot complete with a protocol lower than TLSv1. And I suspect clients which support TLSv1.1 or later probably do not use SSLv2 ClientHello anyway, so this seems to me to be a reasonable configuration.

Are there any known attack vectors I have missed which would make it inadvisable to keep SSLv2 ClientHello support enabled?

Answer 1

In light of the recent DROWN vulnerability, it's now critical you disable SSLv2 protocols on any server that might give the attacker the possibility to do handshakes. It's now considered not only insecure, but highly critical since it can compromise other servers using the same certificate. More information here and here.

SSLv2Hello is secure against it, and can be used since it does not actually make complete handshake but rather negotiate the protocol on which to be made the handshake.

Answer 2

Note: Java/JSSE doesn't implement real SSLv2 (only hello) so no need to disable it. As the linked article says, recent updates disable SSLv3 by default, but you can re-enable it; try not to.

Attacks: I don't think there are any direct attacks from v2Hello, but there may be functional limitations. Primarily it prevents use of extensions, some of which are now important or vital: SNI may be needed for virtual hosts or similar; ECcurves and possibly sigalgs may be needed to correctly negotiate preferred or even usable crypto. (Renego_info is needed on any subsequent handshake, but that should step-up the format, although I haven't checked; on the initial handshake emptyRI-SCSV is enough and seems mostly preferred anyway.)

Clients: OpenSSL 0.9.8 commandline s_client defaults to v2hello, but -no_ssl2 or more specific -ssl3 or -tls1 fixes it; an app using any OpenSSL must either select a specific protocol, or use the (now-misnamed) "v23" method to support a range which may be explicit, except that in 1.0.0+ "v23" automatically deselects SSLv2 protocol and v2hello format if the cipherlist doesn't include any SSLv2 ciphers, and the default cipherlist doesn't. Java6 client v2hello can be disabled in the app, if it is hardcoded to do so, configurable to do so, or you have source and can change it -- or at least the relevant part(s) of it, given that many Java applications are mostly libraries plus glue.