JDK-4915862 : Documentation of "SSLv2Hello" could be made clearer
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2003-09-02
  • Updated: 2004-08-20
  • Resolved: 2004-08-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 rcFixed
Description
****
Submitter did not understand the intent of SSLv2Hello.  This should
be clarified, and include the effects of what happens on both client
and server sides.
Brad
****

When disabling "SSLv2Hello" on the server (by calling
javax.net.ssl.SSLServerSocket.setEnabledProtocols with a string array
containing "SSLv3" and "TLSv1"), I get this exception:

  javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled

on the server when the client initiates a handshake.

In order for this to work, I also need to explicitly disable
"SSLv2Hello" on the client.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-rc
02-09-2004
EVALUATION I do not follow. The only effect of disabling SSLv2Hello on the server is that connections from client sending an SSLv2 hello message are rejected. If you do not want that to happen, why do you disable SSLv2Hello? ###@###.### 2003-09-02 -------------------------------------------------------------------------------- OK, I may have misread the log output. When I don't disable any protocols, the client dumps this output: *** ClientHello, v3.1 [...] main, WRITE: SSL v3.1 Handshake, length = 59 [write] MD5 and SHA1 hashes: len = 77 0000: 01 03 01 00 24 00 00 00 20 00 00 05 00 00 04 01 ....$... ....... 0010: 00 80 00 00 09 06 00 40 00 00 0A 07 00 C0 00 00 .......@........ 0020: 12 00 00 13 00 00 03 02 00 80 00 00 11 3F 54 CF .............?T. 0030: 3D 58 95 BF 01 FC 70 C2 70 38 33 5C DE 50 69 8C =X....p.p83\.Pi. 0040: A6 24 DD 0E 04 A8 39 50 C9 8A F7 11 D9 .$....9P..... main, WRITE: SSL v2, contentType = 22, translated length = 16310 I assumed the client was initiating a v3.1 handshake (since that's what the log says), until I read the fine print ("SSL v2"). Also, why is the client sending an SSLv2 ClientHello if it also supports "SSLv3" and "TLSv1"? According to the TLS protocol specification, it should send the highest valued protocol version it supports: client_version The version of the TLS protocol by which the client wishes to communicate during this session. This should be the latest (highest valued) version supported by the client. It is not intuitive that by enabling "SSLv2" on the client (simply by not calling SSLSocket.setEnabledProtocols), you're automatically disabling the higher valued protocol versions. ###@###.### 2003-09-02 (As I was getting ready to save the bug, Jan called and I was able to clarify his question, which is "how do I disable SSLv2 on the server?". I will leave my original response for our tech writer.) Reading the description, this is behaving as designed. However, the followup in the evaluation leads me to believe that there is a misunderstanding in how this works. Let's make sure we're on the same page here. There's several properties to select the 3 currently known protocols: "SSLv2", "SSLv3", "TLSv1". JSSE in JDK does not currently support SSLv2. Now for compatibility reasons, some protocols such as SSLv3 and TLSv1 allow sending SSLv3/TLSv1 hellos encapsulated in an SSLv2 format hello. See RFC2246, appendix E. However, some SSL/TLS servers don't like the v2 format, and insist client hellos be SSLv3 or TLSv1 client hello format. "SSLv2Hello" option allows people to turn on/off the SSLv2->SSLv3 Client hello mapping. If the option is turned off on the client, then all outgoing messages will be in the SSLv3/TLSv1 client hello format. If the option is turned off on the server, all incoming messages must conform to the SSLv3/TLSv1 client hello format. So, what exactly is it you're trying to do? disable SSLv2? If you do not want to use SSLv2, then make sure "SSLv2" is not in the list of strings passed to setEnabledProtocols(). disable SSv2Hello->SSLv3Hello/TLSv1Hello mapping make sure "SSLv2Hello" is not in the list of strings passed to setEnabledProtocols() ###@###.### 2003-09-02 ----------------------------- I updated the SSLv2Hello entry in Appendix A of the JSSE Reference Guide with the following entry: Currently, the SSLv3 and TLSv1 protocols allow you to send SSLv3 and TLSv1 hellow encapsulated in an SSLv2 format hello. For more details on the reasons for allowing this compatibility in these protocols, see Appendix E in RFC 2246: The TLS Protocol Version 1.0. Note that some SSL/TLS servers do nto support the v2 hello format and require that client hellos conform to the SSLv3 or TLSv1 client hello formats. The SSLv2Hello option controls the SSLv2 encapsulation. For example, if SSLv2Hello is disabled on the client, then all outgoing messages will conform to the SSLv3/TLSv1 client hello format. If SSLv2Hello is disabled on the server, then all incoming messages must conform to the SSLv3/TLSv1 client hello format. ###@###.### 2004-03-16
16-03-2004