JDK-4483157 : wrong alert code during SSL V2 ClientHello
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2001-07-23
  • Updated: 2010-07-28
  • Resolved: 2010-07-28
Description
	Reading the JSSE source code indicates that it is likely
returning SSL V3 alert codes upon any failures detected during the
parsing of an incoming SSLV2 Client Hello.
Comments
EVALUATION A SSLv2Hello does not suppose the client use SSLv2. As SSLv2 is out-of-date and SSLv2Hello is fade out, we will not fix the defect.
30-07-2010
PUBLIC COMMENTS A SSLv2Hello does not suppose the client use SSLv2. As SSLv2 is out-of-date and SSLv2Hello is fade out, we will not fix the defect.
28-07-2010
EVALUATION ***Important, please ignore the v2NoCipher comment about the cipher suite number for SSLv2 being 0x0200, it should be 0x0002, I didn't check the spec before writing the below report, everything is fine with regards to that value*** From some of the email: On Mon, 15 Apr 2002, Brad Wetmore wrote: > >> It does looks broken to me. You could create an exception that > >> triggers clearPipeline to close the socket in a SSLv2 way, because > >> fatal (SSLSocketImpl:line 722) does it in a V3 way. > > > >I haven't really followed this, but there is code in InputRecord that > >sends an SSLv2 alert if it encounters a bad SSLv2 client hello message. > > I think what will happen is: > > if anything in InputRecord.handleUnknownRecord()/read() throws > an exception, this propagates back out to > SSLSocket.clearPipeline (line 718) which calls fatal (line > 721/SSLProtocolAlertException and 725/SSLProtocolException), > sends an error in v3, then shuts down the connection. Note > that an EOFException doesn't call fatal, but rather just > invalidates the InputRecord. > > You do check if (recordVersion == ProtocolVersion.SSL20Hello) { > and send a "v2NoCipher" down the pipe, but then you throw the > exception and fatal is again called, sending another alert > down the pipe. > > I haven't looked into what happens when you throw a > SSLException from InputRecord. Offhand it looks like it > just propagates out with no closing. > > This whole area could use an examination. > > brad Before Andreas putback: I had done some testing by sending a SSLv2 message to a JSSE server, the server sends back "v2NoCipher" alert (if SSLv2Hello is enabled, which is by default) to the client and throw SSLException: javax.net.ssl.SSLException: Unsupported SSL v2.0 ClientHello If SSLv2Hello is disabled on the server-side then a v3 handshake-failure alert will be sent to the client. -Jaya =================== Didn't have time to check this out further in hopper, maybe for mantis or tiger. It's not a critical issue, so we'll defer it. ###@###.### 2002-04-23 I've just confirmed it. If you shut down the output in the middle of the client hello, you will get a v3 alert message, not a v2 message. 15 03 01 00 02 02 0a which translates to a V3 alert (instead of a v2 error): 15 alert 03 01 Version 00 02 Length 02 0a Fatal-unexpected message ###@###.### 2002-08-23 ****IGNORE BEGIN**** Also, the code for checking if you should send a v2NoCipher in response to a SSL20Hello is incorrect, it is testing for procotol version 0x0002 instead of 0x0200. ###@###.### 2002-08-26 (See Attachment Client.java) 1) When a client sends a valid V2Hello for a V2 client, we don't recognise it. Fix is: ProtocolVersion.java: [wetmore@summer] 252 >sccs diffs ProtocolVersion.java ------- ProtocolVersion.java ------- 35c35 < final static ProtocolVersion SSL20Hello = new ProtocolVersion(0x0002, --- > final static ProtocolVersion SSL20Hello = new ProtocolVersion(0x0200, I've checked all users of ProtocolVersion, I think this is the right fix. ****IGNORE END**** 2) After we send our v2NoCipher error code, we also send a regular v3 error message. InputRecord.line 456; throw new SSLException("unsupported SSL v2.0 ClientHello"); returns back up the stack and triggers fatal(). [wetmore@bongos] 238 >java Client 80 03 00 00 01 - v2NoCipher 15 03 01 00 02 02 0a - v3 error. alert 3.1 2 bytes fatal/alert_unexpected_message 3) This last one is really a corner case that I'm not as hot to fix after making sure that the other cases are handled. The original bug described in is still there, in that if you receive only part of a V2Hello, for example change os.write(output) to os.write(output, 0, 5); You will get the following: Length 0x80/0x31 MSG_CLIENT_HELLO 0x01 CLIENT_VERSION_MSB 0x02 CLIENT_VERSION_LSB 0x00 ... EOF I think all of the other cases are handled correctly, these are the only ones I could see. Then you still have the same handleException, but in a different place.
02-09-2004
PUBLIC COMMENTS Bad generation of protocol alert codes when parsing an incoming SSL V2 ClientHello.
02-09-2004