JDK-8329986 : TLS Session Resumption loses track of SSLSession values
  • Type: CSR
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P3
  • Status: Provisional
  • Resolution: Unresolved
  • Submitted: 2024-04-09
  • Updated: 2024-04-29
Related Reports
CSR :  
JDK-8215933 - TLS Session Resumption loses track of SSLSession values
Description
Summary
-------

This change seeks to clarify the behavior of the `SSLSession.getValue()` method after TLS session resumption via the use of stateless session tickets.

Problem
-------

The behavior of `SSLSession.getValue()` can change when TLS stateless session tickets are enabled on the server side.  With stateless tickets disabled, values set via the `putValue()` method will be preserved across resumed sessions as the sessions are managed by the server.  However, the stateless ticketing feature is enabled by default.  When enabled on the server, a client also enabling this feature during the handshaking process will cause any `SSLSession` values to be omitted when creating stateless tickets.  This is the intended behavior, but it is not documented anywhere.

The goal of this change is to provide additional information to the developer for the SunJSSE implementation's use of the `jdk.tls.server.enableSessionTicket` System property and its impacts on the return value of the `getValue()` method after a session has been resumed with a stateless session ticket.

Solution
--------

The proposed solution is an `implNote` added to the `SSLSession.getValue()` method which explains how the `jdk.tls.server.enableSessionTicketExtension` System property can impact the return value from these methods, and that the behavior can vary depending on the client's willingness to use stateless session tickets for TLS resumption.

Another solution would be to expand on the section related to stateless session tickets in the "Java Secure Socket Extension (JSSE) Reference Guide"

Specification
-------------

```
diff --git a/src/java.base/share/classes/javax/net/ssl/SSLSession.java b/src/java.base/share/classes/javax/net/ssl/SSLSession.java
index 3e1a2b94c0a..f3fd03250ec 100644
--- a/src/java.base/share/classes/javax/net/ssl/SSLSession.java
+++ b/src/java.base/share/classes/javax/net/ssl/SSLSession.java
@@ -176,6 +176,14 @@ public interface SSLSession {
      * For security reasons, the same named values may not be
      * visible across different access control contexts.
      *
+     * @implNote
+     * When stateless session tickets are used by SunJSSE, bound values set by
+     * {@link SSLSession#putValue(String, Object)} are not retained for resumed
+     * sessions.  If maintaining bound values across resumed sessions is a
+     * requirement then the
+     * {@systemProperty jdk.tls.server.enableSessionTicketExtension} should be
+     * set to false.
+     *
      * @param name the name of the binding to find.
      * @return the value bound to that name, or null if the binding does
      *          not exist.

```
Comments
[~xuelei] I am not aware of customer complaints. In looking around on the web at large for discussions I have not found much. There are many sites that document putValue/getValue behavior similar to the official Javadoc, but not much about the impact of stateless session tickets on them. I'm not aware of any escalations in this area. It is possible they are out there, I just haven't come across them yet. That said, I respectfully disagree with your statement that documenting this current behavior through an implNote would prevent future development in this area. The implNote itself in this case is specific to SunJSSE behavior and per the implNote description an implNote can change from release to release and may differ across platforms/vendors/versions. Providing some additional clarity on how things behave today would help consumers of the API, not harm them. I'm will avoid discussing in detail your proposed mitigation example here since this is a CSR, but I would point you to Daniel Jelinski's thorough discussion of the issue in the main bug tied to this CSR. I do think your proposed solution, as I understand it, would introduce more - not less - variability into the API behavior. Stateless session tickets are already very large and adding additional data to them is not desirable. But regardless of the feasibility of any proposal, the statement that the proposed documentation would block any solution in future releases is not consistent with the rules surrounding implementation notes.
29-04-2024
Moving to Provisional.
25-04-2024
FYI. The original bug was submitted as a bug because of the compatibility issues introduced by stateless session tickets, rather than a bug for documentation clarification, if I could recall correctly. If an application uses bound values and upgrade to use stateless session tickets, it is possible to run into the issue. Clarifying the issue in Java doc might not actually mitigate the existing compatibility issues. If there are customers complaining about the issue, it might be a real issue that the case was used in practice. With this specification update, it might be harder to get the issue resolved if it is real in practice in the future. If I am right, it is still possible to mitigate the impact by support bound values with stateless session tickets if the issue is real, for example wrapping small-size serializable values in the session tickets. This specification update will block this kind of future effort. If there is no customer complains and not a real problem, it looks good to me to clarify the documentation.
25-04-2024