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

- For SSLSocket usage: aren't connection closed upstream anyhow when we throw an exception?  
- For SSLEngine usage: SSLEngine has no notion of connection.
- For both usages: `SSLCipher` and `SSLSocketInputRecord` have no context, we don't know if we are at handshake stage or not , etc. We check for all this at SSLTransport that has the context. Besides, it's better to process the alert and finish the handshake nicely than just cut the connection.

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

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