Responding to:
https://mail.openjdk.org/pipermail/security-dev/2024-May/039423.html

This message describes a TLSv1.3 situation where a client gave up waiting for a server to respond with a serverHello, and tries to close the connection instead.  The server then fails to read the response as there is not enough data to decrypt the AES/AEAD/GCM tag, and throws an Exception.

Background:

In TLSv1.3, we correctly switch both read/write ciphers after sending the ServerHello/EE/Certs/etc./Finished flight, so the return client flight is expected to be encrypted.  Due to the timeouts, the client doesn't receive the server's keyshare, and thus can't begin encrypted transfers.

The client thus sends a plaintext Alert/close_notify (2 bytes) to indicate the attempted closure.  The server tries to decrypt the bytes provided, but the inbound data doesn't have enough bytes for a GCM label (16 bytes):  thus the exception and failure observed.  Reproducer based on SSLEngineTemplate attached.

The reason we don't see this on 1.2 is that we switch ciphers on the server AFTER the client's return flight, so the Alert/close_notify will be successfully parsed if the stall happens in the same place.

One option:  on decrypt failure on the initial client return flight, we could try a single unencrypted parse to see if it's an Alert/close_notify|user_cancelled, and handle accordingly.

The original message mentions JDK-8221218, but this bug and friends are test issues which trigger the same exception, and likely unrelated to this issue.