RFR: 8331682: Slow networks/Impatient clients can potentially send unencrypted TLSv1.3 alerts that won't parse on the server [v20]

[Xue-Lei Andrew Fan]

On Thu, 17 Oct 2024 16:13:58 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java line 266:
>> 
>>> 264:         recordBody.flip();
>>> 265:         // Record is ready to be decoded, save it.
>>> 266:         saveLastDecodeRecord();
>> 
>> It might be heavy to cache last decode record for every input record.
>
> Yes, but only if you consider the low probability of needing this record. Overall performance impact should be negligible considering all the other operations we do. I couldn't think of a better way of passing this record upstream, unless we restrict `saveLastDecodeRecord` to contentLen of `2` which will make this not a general purpose method.

The last record could be huge and keep in the memory for a while.  It may be not required to cache it if we are able to close the connection while receiving an alert.  For TLS 1.3, the connection should be closed for alter message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21043#discussion_r1805146851