RFR: 8328608: Multiple NewSessionTicket support for TLS

John Jiang jjiang at openjdk.org
Fri Jun 21 23:28:13 UTC 2024


On Fri, 21 Jun 2024 15:35:46 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Let me start from the beginning and hopefully it will clear things up.
> 
> Today, each Finished connection gets one resumption ticket. That session's SSLContext contains the cache. When someone wants to resume, they use the same SSLContext to make a new session. That new session will look into the cache, find the resumption ticket, and take it out to use. Tickets are one-time use. On completion of the resumed session, a new ticket is placed into cache under the same entry as the previous one.
> 
> Clients that want to open parallel sessions are unable to use resumption effectively. The current client cache can only hold one ticket, throwing away any other tickets the server may have sent it. Additionally, the time between taking the resumption ticket and receiving a new ticket is too slow for parallel connecting clients. The first resumption session takes that ticket, while the second resumption session sees no ticket and has to do a full handshake. This change allows multiple tickets to be stored on the client cache, solving the parallel clients problem, without the application having to change.
> 
> If the application uses new SSLContext instances for each connection, it does not have access to the same cache. This change does not modify that.

Thanks for this clarification.
I was not clear how can multiple connections apply all the cached tickets in parallel.

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

PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2183575943



More information about the security-dev mailing list