In older releases, we introduced the jsse.SSLEngine.acceptLargeFragments System property to workaround implementations that didn't properly implement the 2^14 byte length limitation. The wording in RFC 2246/4346 (TLSv1/1.1) sort of allowed for implementations to exceed this number:

    length
      The length (in bytes) of the following TLSPlaintext.fragment. The
      length should not exceed 2^14.

*NOTE* "should not..."

But that wording was tightened up in RFC 5246/8446 (TLSv1.2/1.3) to be "MUST NOT".

For DTLS in JDK 9, we also added the SSLParameters.setMaximumPacketSize and SSLParameters.getMaximumPacketSize, which were supposed to limit the network packet size.

Later, the original TLS implementation was rewritten for TLSv1.3 and DTLS and we added support for RFC 8449.

During the review of an ignored test, it was noted that the various length options are not playing well with each other. For example, when calling:

    int appBufferMax = session.getApplicationBufferSize();
    int netBufferMax = session.getPacketBufferSize();

these do not take into account the setMaximumPacketSize value or the negotiated value later. The InputRecord/OutputRecords are negotiated using the MaxFragExtension, but don't respect the acceptLargeFragments value.

Then later on after the handshake is complete, the application data code doesn't respect the jsse.SSLEngine.acceptLargeFragments value and reverts to the original length of 2^14.

This area needs a good review to make sure that lengths are being done consistently.

In the default case with jsse.SSLEngine.acceptLargeFragments set, we are properly enforcing the 2^14 length, but functionally the lengths when using jsse.SSLEngine.acceptLargeFragments and setMaximumPacketSize may not be working as expected.

This probably goes all the way to JDK 8u, given that the TLSv1.3 was backported to 8u.