Skip to main content
Information Security

Return to Answer

replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link
Community Bot
Community Bot
  • 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 pushstrong 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.

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.

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.

Source Link
Tom Leek
Tom Leek
  • 173.8k
  • 29
  • 352
  • 483

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.