See the attachment. You should be able to run it by
untarring/compiling.

The following is from Tim, he analysis is mostly correct,
except that that the failure occurs on the client side
when the client denies the server's credentials.
 
The client is then able to read the handshaking data
as though it were app data.


==============
I've tracked down a problem that seems to be the cause of occasional
failures in my Jini security provider code, which uses JSSE.

Here's the situation:

* Connect JSSE sockets on client and server sides. In our case we layer
  the JSSE sockets on top of plain sockets, although that doesn't seem
  to be needed to reproduce the bug.

* Perform an initial handshake on the socket. The handshake succeeds,
  but the client side determines that it needs to use different
  credentials.

* Perform a second handshake, using another thread reading zero bytes to
  keep the handshake going so that we can insure the handshake is
  complete before sending data.

* In the problem case, the second handshake fails on the server side,
  for example because the client credentials have expired.

* The zero byte read throws an IOException, but subsequent reads from
  the socket input stream on the client side do not. Seems like this
  behavior is incorrect: the socket input stream should continue to
  throw IOExceptions.

I've included a test case below, including the needed keystore and
truststore -- just run the JSSESwitchCloseBug class with no arguments
after unpacking the keystores into the current directory. I'm happy to
submit this to bugtraq if you agree that this is misbehavior from JSSE.

I reproduced the problem on Solaris using JDK 1.4 Beta 2, as well as
Beta 3 build 82.

- Tim
==============

###@###.### 2001-10-15