JDK-6728126 : Parsing Extensions in Client Hello message is done in a wrong way
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_vista
  • CPU: x86
  • Submitted: 2008-07-21
  • Updated: 2011-05-18
  • Resolved: 2011-05-18
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.
JDK 6 JDK 7 Other
6u12Fixed 7 b41Fixed OpenJDK6Fixed
Related Reports
Relates :  

In sun.security.ssl.HelloExtensions.java the code for parsing the extensions that exists in a Client Hello message exists. When Java finds an extension it don't support it uses UnknownExtension.

I wrote an XMPP client using Twisted that communicated with an Openfire server. And my client sends a Client Hello message containing the extension Session Ticket (RFC 4507). According to the RFC one should left Session Ticket empty for telling the server that the client supports Session Ticket but it don't have a Session Ticket yet.

When UnknownExtension tries to parse that message it tries to read 0 bytes. And if the Session Ticket is last in the message ByteArrayInputStream::read(byte b[], int off, int len) returns -1 because we reached end of file and that means that HandShakeInStream::read(byte b[], int off, int len) throws an exception because it tried to read 0 bytes and got -1 back.

I have no idea where the check for trying to read 0 bytes should be.

But if I have a buffer of 20 bytes and first reads 20 and then tries to read 0 bytes. Should I really get -1 then? Shouldn't it be allowed to read 0 bytes if eof isn't yet reached?

I've also posted in the Openfire forum: http://www.igniterealtime.org/community/thread/33945

If you need any more info just contant me.

This bug can be reproduced always.

Twisted uses OpenSSL so if I turned off Session Ticket using SSL_OP_NO_TICKET there was no problem.

EVALUATION The inputstream.read(byte[], int, 0) is not always expected return 0 in the case of the bug description. We should not try to read zero bytes from inputstream.