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 15:55:29 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Does it happen in server side (server send plaintext) as well?  I found some cases that the client decryption failed.
>
>> Does it happen in server side (server send plaintext) as well? I found some cases that the client decryption failed.
> 
> Current reports indicate it happens on the server side only (server throws the exception). Please share any cases when it happens on the client side. This PR has a check to handle this scenario on the server side only.

> > @artur-oracle Thank you for update.
> > It may be too later, but if there is a chance it might worthy of an update so that it can take care of more cases. In the SSLCipher decrypt() implementation, the content type of the input record is already known. If the content type is alert, and decryption failed or insufficient buffer, does it sound reasonable to you to close the connection immediately?
> 
> I'm not sure how it would be different from the current state, what do you mean by `close the connection immediately`?

Currently, if an alter message cannot be decrypted, exception thrown.  When alert is received, if it is not decryptable, treat it as an alert and close the connection accordingly, without sending more message to peers.

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

PR Comment: https://git.openjdk.org/jdk/pull/21043#issuecomment-2420110154