On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino <ascarp...@openjdk.org> wrote:
> Hi > > This change is to improve TLS 1.3 session resumption by allowing a TLS server > to send more than one resumption ticket per connection and clients to store > more. Resumption is a quick way to use an existing TLS session to establish > another session by avoiding the long TLS full handshake process. In TLS 1.2 > and below, clients can repeatedly resume a session by using the session ID > from an established connection. In TLS 1.3, a one-time "resumption ticket" > is sent by the server after the TLS connection has been established. The > server may send multiple resumption tickets to help clients that rapidly > resume connections. If the client does not have another resumption ticket, > it must go through the full TLS handshake again. The current implementation > in JDK 23 and below, only sends and store one resumption ticket. > > The number of resumption tickets a server can send should be configurable by > the application developer or administrator. [RFC > 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default > value. A system property called `jdk.tls.server.newSessionTicketCount` > allows the user to change the number of resumption tickets sent by the > server. If this property is not set or given an invalid value, the default > value of 3 is used. Further details are in the CSR. > > A large portion of the changeset is on the client side by changing the > caching system used by TLS. It creates a new `CacheEntry<>` type called > `QueueCacheEntry<>` that will store multiple values for a Map entry. This enhancement allows the server side to send multiple tickets and the client side to store multiple ones. However, how does the client side use the tickets in the cache? This PR just takes the client side to find the first valid ticket from the cache queue to try to resume the session. Since the tickets are generated by the server in bulk, so their lifetimes are almost the same. Generally, the first valid ticket is the first ticket in the cache queue (otherwise, no valid ticket can be found). What about the remaining tickets? They are unlikely to be used. Furthermore, now that no public API supports the client-side applications to access the cached tickets, so the clients cannot use all the tickets for resuming multiple sessions in the subsequent connections. Then, could this PR not change the cache? The client still stores the last ticket sent by the server in a connection. That can simplify the solution and implementation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2179830838
