FULL PRODUCT VERSION :


A DESCRIPTION OF THE PROBLEM :
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.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Twisted uses OpenSSL so if I turned off Session Ticket using SSL_OP_NO_TICKET there was no problem.
Posted Date : 2008-07-21 23:24:53.0

N/A

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.
Posted Date : 2008-11-18 03:58:33.0