United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4836493 Socket timeouts for SSLSockets causes data corruption
JDK-4836493 : Socket timeouts for SSLSockets causes data corruption

Details
Type:
Bug
Submit Date:
2003-03-24
Status:
Resolved
Updated Date:
2005-09-29
Project Name:
JDK
Resolved Date:
2005-08-05
Component:
security-libs
OS:
solaris_9,generic,windows_2000
Sub-Component:
javax.net.ssl
CPU:
x86,sparc,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
orion3,1.4.2,5.0
Fixed Versions:

Related Reports
Backport:
Backport:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:

Sub Tasks

Description
The Sun JSSE implementation does not fully support socket timeouts (Socket setSoTimeout() method). If the timeout occurs while reading the first bytes of the record, timeouts work as expected. However, when the timeout occurs in the middle of reading a record, we "forget" that we already have partial data in the record buffer. This causes subsequent reads to fail with an SSLException.

Typically, we will receive all TCP packets that make up an SSL record in quick succession. This makes it very unlikely that a timeout occurs in the middle of reading a record. Consequently, timeouts will work in those cases. However, there may be situations where this does not hold, which would make applications that use socket timeouts with SSL sockets unreliable.

Still, I am filing this as a low priority bug because timeouts are typically used for two reasons:

 . simulate non-blocking I/O by setting the timeout to a low value (1 ms). This is vastly less efficient than the real non-blocking I/O functionality offered by the NIO APIs, which will be supported with JSSE in Tiger (see 4495742). Therefore, this pattern should no longer be used.

 . detect "dead" peers. In many cases, the socket will simply be closed if a dead peer is detected. As such, it does not matter if further reads from the socket would fail.

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
dragon


                                     
2004-09-02
EVALUATION

Too late for Tiger. Will investigate for Dragon.

###@###.### 2003-12-05

The problem is that InputRecord sets count as soon as it reads the 5 byte record header. If a timeout occurs on subsequent reads, we just escape from that method. So the next time the application calls read(), we think there is valid data in the record and return it even though they are only old or still encrypted bytes.

What we should do is set a flag when be begin reading a record, keep the current read index in a separate variable, and only update count and other variables once we have read the complete record. That way we know that and where to resume after a timeout exception occurs.

###@###.### 2005-05-26 22:27:36 GMT

All of the work will probably be in InputRecord.java.  I think we currently catch/ignore the SocketTimeout exception in the SSLSocket code.  What I don't know for sure is whether each arch throws the proper exception.  You'll need to make sure this works on every platform.  You'll also need to think about what an interrupted SSL handshake means in this context.  Things like startHandshake() assume that the initial handshake will have been successfully completed before it returns.


###@###.### 2005-05-27 01:22:20 GMT
                                     
2005-05-27



Hardware and Software, Engineered to Work Together