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

[Artur Barashev]

On Thu, 17 Oct 2024 17:22:54 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> 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.

It can't be more than 16KB. Alternatively we can update `BadPaddingException` to actually store the data that we failed to decrypt and pass it upstream that way, what do you think about that?

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

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