On Wed, 29 Oct 2025 03:51:13 GMT, Jamil Nimeh <[email protected]> wrote:
>> 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/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?
- Do you mean to use a different log message? The stateless session resumption
is enabled by default, so if server doesn't send "session_ticket" extension we
disable it on the client side.
- We support DTLSv1.2 only and in v1.2 NST must come before CCS and finished,
so verifying Finished would fail if NST goes missing (server and client would
have different handshake hashes) - that's exactly what happens in this ticket
we are fixing. And yes, CCS would set a new epoch.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2473828413
