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

[Artur Barashev]

On Tue, 24 Sep 2024 20:19:58 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Can’t review it, still don’t understand how the error condition happens. (But I do know massive problems with extra messages sent when a broken connection is wound down - it might want to use aggressive timeouts for those graticious messages)
>
>> Can’t review it, still don’t understand how the error condition happens. (But I do know massive problems with extra messages sent when a broken connection is wound down - it might want to use aggressive timeouts for those graticious messages)
> 
> I think the issue is described clearly in the bug ticket:
> https://bugs.openjdk.org/browse/JDK-8331682
> 
> Please let me know if you have any specific questions.

> @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`?

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

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