From the java-security alias:

From Mathias:

I am using JSSE 1.0.2 and I am encountering a serious problem. When
using the SSLSocket class, I set the timeout for the socket just as you
would do with the standard Socket class. After this when I try to read
from the sockets input stream and no input is available ie the timeout
occurs, then all subsequent reads from the input stream return
immediately the value null. This is not very practical for obvious
reasons and I wonder why this is the case. Is there a work-around for
this? At my work I am working with communication protocols that I am
now trying to convert to SSL with JSSE but this is a severe problem
since the semantics is Very different from standard Sockets.

I am very grateful for a reply that explains the situation for me.


From Greg:

I have been working with JSSE 1.0.2 for a couple months now. My last
problem (how to get an existing private key into a JavaKeyStore) was
solved with the kind assistance of Mr. Brad Wetmore from Sun, a regular
poster on this list. Hopefully he or another good soul can help me with
my new problem.

I have been trying to add SSL support to an existing class. My strategy
is fairly straightforward: In the section of code that acquires a
socket, I added the option of generating an SSLSocket instead of a
regular Socket. The socket is treated normally from then on.

The next thing the class does is to call the socket's setSoTimeout()
method, so that reads won't block for longer than a second. Then it
goes into an infinite loop, reading from the socket, and checking
various other things between reads. The read is supposed to throw
InterruptedIOException if no data arrives after the timeout expires.
For a normal socket, that's exactly what happens. For an SSLSocket, the
socket acts as if it has hit EOF.

I have also run into this problem with a new class I am writing,
designed to act as an SSL proxy. If I set an SO Timeout, and the
timeout expires, the SSL socket (more specifically, the input stream
acquired from the socket) acts as if it is closed. The read() call
returns -1 bytes read. A normal socket run through the same exact code
throws InterruptedIOException.

This looks to me like a bug in the JSSE reference implementation. I'm
open to the possibility that it is really my own problem, but I doubt
it--the existing class is old code and well-tested. For reference, I am
using Sun's Java 2 SDK version 1.3 for Linux.

Any thoughts?


From Greg again:

I sent a message about this problem once before, on the 11th. I have
received no response, and the java-security archives web page gives no
indication of whether my message was even received. (The most recent
message I see on that page is from Jan. 9th. How often is the archive
updated?)

Again, my problem is that if I call setSoTimeout() on an SSLSocket, and
no data arrives before the timeout, the socket closes. It is supposed
to throw InterruptedIOException.

I have a workaround, although it is ugly. I've found that if I close
the SSLSocket, the read() dies with a SocketException: "socket closed:
Bad file descriptor". Then I have to conceal this exception from the
user so they don't think the program is broken. Normal sockets don't
work this way; if you close them, the blocking read() doesn't die, and
the thread hangs forever--it can't be killed even with stop(). So for
normal sockets, I am still using the setSoTimeout(). (You see?
Hideous.)

I'm still hoping the bug in JSSE can be found and corrected, or that
someone can tell me what I'm doing wrong that causes the SSLSocket to
close instead of throwing InterruptedIOException.

From Greg one week later:


Hello. Thanks for responding to both my problems.

I submitted this as a bug on the Sun BugParade site last week. It has been
assigned internal review ID 115725. The email confirmation suggests it will
take three weeks for it to be assigned a bug tracking number. Once we have
a tracking number, we can put it in our product's release notes, and explain
that the unsightly behavior they see in our product is the result of a
workaround for that bug.

I'm now more sure than ever that it really is a JSSE bug and not a problem
with my own code, since I discovered someone had posted a message in a Java
Forum describing the exact same symptoms, although he was using Windows
rather than Linux. I made sure to include a URL to the other poster's
message in my bug report, since he had already included a code snippet
demonstrating the bug.

So, you needn't do anything about this issue. I'm just going to wait for
the BugParade people to check it out. When I get a tracking number, I'll
post it here so others can see it.

I'm somewhat surprised to hear that this list is archived by hand. If it
were my web site, I would've written a Perl script to do the job. I would
expect Sun to be using a servlet. That's why I started to think the list
was down when I didn't see my message appear. Since I can't subscribe to
the list, I had no way of knowing if my message got through.

Thanks again for your response.

Greg Meyers
I/O Concepts Developer, Webmaster
###@###.###


From Columbia University:

Name: krC82822 Date: 02/09/2001
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
 
It's hard to provide some working source code, because JSSE socket
creation isn't short. I have test client and server application, both
can create either JSSE or regular sockets. They send strings to each
other.
 
Both JSSE and regular socket examples worked fine if timeout was not
set for the socket.
 
But if I set timeout (actually, I tried to do it on the server side):
socket.setSoTimeout(10000); and deliberately delay some sending, I
get:
 
"java.io.InterruptedIOException: Read timed out" in the case of plain
sockets, which I consider as correct result;
 
and end-of-file condition (socket.getInputStream().read(buffer) returns
-1). in the case of JSSE sockets.
 
When sendings are not delayed, messages pass fine, so it's really
timeout condition was treated as end-of-file.
 
(Review ID: 109214)
======================================================================