On Mon, 13 Oct 2025 17:28:06 GMT, Artur Barashev <[email protected]> wrote:
>> If the NewSessionTicket message is lost, the handshake fails on the client
>> side with:
>> javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message
>> cannot be verified.
>
> Artur Barashev has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Restore "createSSLEngine" access privileges to make existing tests pass
src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java line 1631:
> 1629: && (!tc.sslConfig.isClientMode
> 1630: || !tc.handshakeContext.statelessResumption
> 1631: ||
> hasCompleted(SSLHandshake.NEW_SESSION_TICKET.id));
Stylistically this is a bit weird putting the comment mid-stream into a complex
logical comparison. I get why you're doing it here, but I think it will be
easier to read things if the comment goes above the return statement.
src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line
551:
> 549: if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
> 550: SSLLogger.info(
> 551: "Server doesn't support stateless
> resumption");
Would it be more accurate to indicate that the client is disabling stateless
resumption due to the missing message? Because, up to that point, the
assumption is that the server does support this kind of resumption and now it's
being turned off.
I'm curious, does this get run and the stateless resumption disabled if this
scenario occurs:
- server receives client finish and verifies successfully
- server sends NST, but it goes AWOL
- server sends CCS
- server resends the lost NST
- server sends finish
Not sure if that scenario can happen since the CCS moves us onto the next
epoch, right?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2471640638
PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2471652428
