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

[Artur Barashev]

On Wed, 18 Sep 2024 11:40:27 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Rather than proactively scanning every packet for this unlikely scenario, we reactively check for unencrypted alert after getting the BadPaddingException
>>   - Add "!context.isNegotiated" check as "handshakeContext" can be non-null if server receives a Post-Handshake message
>>   - Update test to send "close_notify" alert after "user_cancelled" alert
>
> Should the client send a close_notify if the connection is closed in the middle of the handshake? I couldn't find a good answer in the TLS1.3 spec, but I'd assume that closing the connection without sending a close_notify would be good enough.
> Should the server throw a handshake exception when the handshake is aborted?
> Will the server throw the right exception if the client aborts the connection for a different reason (like a server_hello that fails to decode correctly)?

@djelinski I pushed a new commit, please review:

    - Rather than proactively scanning every packet for this unlikely scenario, we reactively check for unencrypted alert after getting the BadPaddingException
    - Add "!context.isNegotiated" check as "handshakeContext" can be non-null if server receives a Post-Handshake message
    - Update test to send "close_notify" alert after "user_cancelled" alert

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

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