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

[Xue-Lei Andrew Fan]

On Fri, 25 Oct 2024 23:44:50 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> 1. If we got through the `bb.remaining() <= tagSize` arm, we're not going to be encrypted.  I think we are safe here.
>> 2. I would dump the alert level (fatal/warning) + reason.
>> 3. `bb` size definitely needs to be checked.  e.g. if `bb.remaining() == 0`, the `bb.position() + 1` will IOOBE.
>
> - Alert level is ignored in TLSv1.3, but we can sure include it it as well
> - Why are we not sure that alert is plaintext? If alert is not a plaintext then contentType will be 23 and we throw BadPaddingException as we should
> - About the bb size: the upstream code (SSLEngineInputRecord/SSLSocketInputRecord) actually makes sure those bytes are present. The above `if (contentType == ContentType.CHANGE_CIPHER_SPEC.id)` code also doesn't include the bb size check.

For example, there is a man-in-the-middle message.

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

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