JDK-6388456 : Need adjustable TLS max record size for interoperability with non-compliant stacks
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 5.0u8,6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-02-21
  • Updated: 2021-09-08
  • Resolved: 2006-04-14
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 JDK 6
5.0u10Fixed 6 b81Fixed
Related Reports
Relates :  
Description
Paraphrased from customer email:

In com.sun.net.ssl.internal.ssl.Record.java, maxDataSize is defined as 16384 as per the TLS 1.0 RFC (http://www.rfc.net/rfc2246.html Section 6.2.1). However, our partner's system is not compatible with the RFC, sending us 30KB TLS fragments. This incompatibility causes the following exception:

javax.net.ssl.SSLProtocolException: Input SSL/TLS record too big: max = 16665 len = 27314
            at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:770)
            at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:674)
            at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:566)
            at com.facetime.imstack.socket.impl.ssl.SslConnection.socketReadEvent(SslConnection.java:157)
            at com.facetime.imstack.socket.impl.nio.NioConnection.selectedEvent(NioConnection.java:208)
            at com.facetime.imstack.socket.impl.nio.NioDispatcher._processSelected(NioDispatcher.java:148)
            at com.facetime.imstack.socket.impl.nio.NioDispatcher.run(NioDispatcher.java:214)
            at java.lang.Thread.run(Thread.java:595)

While this is not a JDK issue, as the JSSE code is correct according to the RFC, it prevents the JDK from interoperating with these non-compliant stacks. The customer requests that the JDK code support interoperability with these stacks, either by being able to specify the maximum record size via a system property or similar, or by having the code dynamically detect incoming packets that are too large and handling them appropriately.

Comments
EVALUATION Besides updating the underlying data structures, this will require some reworking of the SSLEngine's API, as it's currently using the TLS-defined max packet size to determine the values to return via SSLSession.getApplicationBufferSize()/getPacketBufferSize(). These values weren't originally expected to be dynamic, but the language could be updated in the API.
21-02-2006