JDK-4836493 : Socket timeouts for SSLSockets causes data corruption
  • Type: Bug
  • Status: Resolved
  • Resolution: Fixed
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P2
  • Affected Version: orion3,1.4.2,5.0
  • OS: generic,solaris_9,windows_2000
  • CPU: generic,x86,sparc
  • Submit Date: 2003-03-24
  • Updated Date: 2017-05-19
  • Resolved Date: 2005-08-05
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 Availabitlity Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_11Resolved 6 betaResolved
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
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
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

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: dragon
2004-09-02