Client Hello message suggests cipher suite which is not in the list specified by setEnabledCipherSuites() method

Question

In my code, I use JSSE6 API to specify a list of enabled cipher suites. I aimed to only allow 168 bits or higher encryption cipher suites, below is a part of my code:

/** List of 168 bits encryption or higher cipher suites */
private static final String[] ENABLED_CIPHER_SUITES_168 = {
    "TLS_RSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
    "TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
    "TLS_DHE_DSS_WITH_AES_256_CBC_SHA",
    "SSL_RSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA",
    "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
    "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA",
    "TLS_EMPTY_RENEGOTIATION_INFO_SCSV",
    "TLS_KRB5_WITH_3DES_EDE_CBC_SHA",
    "TLS_KRB5_WITH_3DES_EDE_CBC_MD5",
    "SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA",
    "NETSCAPE_RSA_FIPS_WITH_3DES_EDE_CBC_SHA",
    "SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA",
    };
// return a list of cipher suites which match both array
String[] list = matchStringArrays(ENABLED_CIPHER_SUITES_168, ((SSLSocket)socket).getSupportedCipherSuites());
// Set a list of enabled cipher suites
((SSLSocket)socket).setEnabledCipherSuites(list);

But when I test my app with some SSL scanner tool, they say that my server allows 96-bits encryption cipher suites?

Then I use Wireshark to capture packets of then SSL handshake process, I found that in Client Hello message, there's a cipher suite that is not in my list of enabled cipher suites. The cipher suite is

ssl2_des_192_ede3_cbc_with_md5

How can this cipher suite appear in the the client hello message?

Answer 1

The SunJSSE provider does not support SSLv2. It does support sending the first ClientHello message of the SSL/TLS handshake in SSLv2 format, though.

A client sending the ClientHello message in SSLv2 format is useful if the client is ready to actually use SSLv2. However, since SunJSSE does not support SSLv2, it sends the ClientHello in SSLv2 format for a weaker reason: this is to support old, buggy, legacy servers that know SSLv3 but expect the ClientHello in SSLv2 format, and simply hang up when faced with a "normal", SSLv3-format ClientHello (such servers exist because when SSLv3 was designed and deployed, SSL clients soon took to the habit of sending the ClientHello in SSLv2 format, so receiving an SSLv3 ClientHello was not really tested).

This sheds some light on what SunJSSE will do: it will send a SSLv2 ClientHello not to actually do SSLv2, only to be able to connect to some old servers that expect that message format and then proceed to use SSLv3. The SSLv2 ClientHello will also contain, in the list of cipher suites, the codes for the SSLv2 cipher suites -- that the client does not actually support, since it does not know SSLv2. These cipher suites are thus harmless: the client has no intention of using them and indeed does not know how to use them; it includes them just to make the ClientHello message more "SSLv2-like". The client strongly expects the server to respond with a SSLv3 ServerHello, the SSLv2 cipher suite being ignored.

Disabling support for that "SSLv2 ClientHello format" is still a good idea, for the following reasons:

• Though the JDK from Sun/Oracle uses SunJSSE for SSL, another Java implementation may include full SSLv2 support (IBM's implementation is reputed to do that), and you don't want to inadvertently use the complete SSLv2, since it is weak in several ways.

• There is a strong push to disable SSLv2 completely. Servers may cease to support the SSLv2 ClientHello message format. They might be some old buggy servers that require a SSLv2 ClientHello; but there also are some new, non-buggy server that don't support SSLv2 ClientHello; and the latter will be more and more prevalent as time passes.

• Even when they do support it, that format cannot contain SSL extensions, e.g. Server Name Indication, so using the SSLv2 ClientHello format may prove limitative.

Nowadays there is a lot of talk about disabling SSLv3 too, and forcing TLS 1.0 or higher, so clinging to SSLv2 will make you look unfashionably archaic.