JDK-8215933 : TLS Session Resumption loses track of SSLSession values
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2018-12-26
  • Updated: 2024-07-24
Related Reports
CSR :  
JDK-8329986 - TLS Session Resumption loses track of SSLSession values
Relates :  
JDK-8212885 - TLS 1.3 resumed session does not retain peer certificate chain
Relates :  
JDK-8242008 - SSLSession inconsistencies
Relates :  
JDK-8226338 - Updates to Stateless Resumption
Relates :  
JDK-8325384 - sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java failing intermittently when main thread is a virtual thread
Relates :  
JDK-8211018 - Session Resumption without Server-Side State
Description
When TLS sessions are resumed, the retrieved SSLSession object after resumption no longer has values that were set on the original session object.
Comments
Adjusting bug to P4 given the resolution is only a one-liner fix with some additional spec documentation changes.
10-04-2024
Full story: This issue affects stateless session resumption only. With stateful resumption, the session values are tracked just fine. With stateless resumption, the server does not keep the session object or the associated values around; instead, the session is stored (encrypted, as a session ticket) by the client, and sent to the server when the client wishes to resume the session. The stateless session tickets do not contain the session values. Session values are user objects, and might not even be serializable. Even if we serialized them, the session ticket generated during handshake would only contain a snapshot of the values; any changes after the ticket was generated would not be reflected. With TLS1.2 the decision to use stateful or stateless session resumption has to be made during the handshake. Once the handshake is complete, there's no way to switch from stateless to stateful, or the other way round. Technically we could associate state with a stateless ticket, but that would require disproportionate allocation of resources (stateless tickets are often multi-kilobyte, and even comparing them in order to find the right cached session would be a problem) With TLS1.3 the server can send session tickets at any point during the connection lifetime, and is free to interpret them as stateless or stateful. JDK-8226338 changed the server behavior so that any time a session value is set, the server generates a stateful ticket. If the client then uses that ticket for resumption, the server will see the values associated with the original session. If the client uses the original stateless ticket, the session resumed with that ticket will not see the session values. JSSE client implementation currently only caches one (the latest) session ticket per host, so once the client processes the stateful ticket, it will not use the stateless one. JDK-8328608 will probably add support for storing multiple tickets per host. It would probably make sense to update SSLSession documentation to explain that the values associated with a session will not be preserved if stateless resumption is used, and to point users to the property to disable stateless resumption (jdk.tls.server.enableSessionTicketExtension). It might also make sense to deprecate binding values to sessions, to make sure users are aware of the complexity involved.
05-04-2024
The issue affects stateless session tickets, which are produced before the session values are bound. This was fixed in JDK-8226338; once values are bound to a session, a new stateful session ticket is produced and sent to the client. As long as the client uses the new ticket for resumption, the session values will be preserved.
04-04-2024