On Wed, 18 Sep 2024 11:40:27 GMT, Daniel Jeliński <djelin...@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
