JDK-4495742 : Add non-blocking SSL/TLS functionality, usable with any I/O abstraction
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 1.4.0,1.4.1,1.4.2,5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_2000,windows_xp
  • CPU: generic,x86
  • Submitted: 2001-08-23
  • Updated: 2017-05-16
  • Resolved: 2003-08-17
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 Availability Release.

To download the current JDK release, click here.
Other
5.0 tigerFixed
Related Reports
Duplicate :  
JDK-4635458 - NIO/JSSE integration
Duplicate :  
JDK-5084242 - SSLSocketChannel
Duplicate :  
JDK-4808184 - RFE: Support non-blocking SSL sockets
Duplicate :  
JDK-4727279 - RFE: Make an SSLServerSocketChannel
Relates :  
JDK-4836493 - Socket timeouts for SSLSockets causes data corruption
Description
 
The current JSSE javax.net.ssl.SSLSocket API is based on the 
java.net.Socket model, which by nature uses a blocking API model.  The 
introduction of java.nio.channels API (JSR-51) brought a selectable, 
non-blocking I/O model to J2SE, but was not based on Sockets.  Developers
have requested a non-blocking SSL/TLS implementation that could be 
applied to such diverse I/O abstractions, such as:

     Socket-Input/OutputStream
     non-blocking I/O (polling)         (e.g. SocketChannel-nonblocking)
     selectable non-blocking I/O,       (e.g. SocketChannel-Selectors)
     other asynchronous I/O models      (e.g. the proposed JSR 203)
     local ByteBuffers/byte arrays

A new abstraction called SSLEngine is introduced which separates the 
SSL/TLS functionality from the I/O.  The SSLEngine operates simply on 
inbound and outbound byte streams, and it is the responsibility of the 
SSLEngine user to arrange for reliable I/O transport to the peer.  By 
separating the SSL/TLS abstraction from the I/O transport mechanism, the
SSLEngine can be used with a wide variety of I/O types.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b16
02-09-2004
EVALUATION Yes, this is highly desirable, but unfortunately we haven't time to do it for J2SE 1.4. This, or something like it, will be considered for a future release. -- mr@eng 2001/8/23 This is definately on the radar for tiger. ###@###.### 2002-02-08 In JSSE 1.0.x and JSSE in JDK 1.4.x, the SSLContext class is responsible for generating communication sockets that transparently use SSL/TLS as a secure/reliable data transport mechanism. Application data written to a SSLSocket is encrypted and integrity protected before being sent over an unsecured channel. We update this model by creating a javax.net.ssl.SSLEngine class. The primary distinction of an SSLEngine is that the SSLEngine removes all I/O handling and simply operates on the inbound and outbound byte streams. The SSLEngine user is responsible for arranging reliable I/O transport. By separating the SSL/TLS abstraction from the I/O method, the SSLEngine can be used for a variety of I/O types: non-blocking I/O (polling), selectable non-blocking I/O, Sockets-Input/OutputStream's, local ByteBuffers/byte arrays, etc. If developers feel they have a better I/O heuristic for an SSLSocket implementation (say using SocketChannels and a pool of worker threads), they are free to create their own SSLSocket/SSLSocketFactory implementations and register it with the JSSE framework. ###@###.### 2003-07-21
21-07-2003