JDK-8329986 : TLS Session Resumption loses track of SSLSession values
  • Type: CSR
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P4
  • Status: Closed
  • Resolution: Withdrawn
  • Submitted: 2024-04-09
  • Updated: 2025-04-23
  • Resolved: 2025-04-23
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
This CSR has been in Provisional state for some time. A reminder that JDK 25 rampdown 1 start is on June 5, 2025. CSRs intended to get in the release should be Finalized well ahead of the deadline. If there is no longer interest in this CSR, it can be withdrawn.
22-04-2025
> Technically, bound values are still supported if you set the jdk.tls.server.enableSessionTicket system property to false (though that may be undesirable), and this change documents that. I think we are on the same page at this point. The case we cared about and discussed here is to support bound values together with stateless session ticket. > Also, I think it is acceptable to change the behavior of an @implNote in an update release, as long as there was an approved CSR for that change, and it did not affect the specification. I agreed, but there are two assumptions here: the CSR get approved and no affect on the specification. How to make sure the CSR could be easily get approved and there is no affect on the specification is one of the goal we want to address in the discussion, I think. In another word, what if the CSR will not be approved and the specification get affected in the future? In another viewpoint from developers, the case is not supported in 21u1 and application is coded to use SunJSSE provider accordingly. And then in 21u3, the case is supported in 21u3 and the previous good application run into compatibility issues. The update is total conflict with the precious behavior. We can say that we make the CSR approved for 21u3, but the compatibility issue is real. We also can say developers should not rely ImplNote and we are not take the responsibility, but the compatibility issue is still real. Let us try to clean up the case from the bug itself. The first question is: will we fix the issue in the future? If we can give a clear answer that we will not fix the issue in the future, then we can go ahead with a simple doc clarification. Otherwise, it may be not easy to make an agreement because clarify a bug in java doc may be not common. Then, will we fix the issue in the future? To answer this question, we may need to figure out what's the impact and if there is a workaround. The impact is when an application upgrade to later release, it will use session ticket by default, and bound values may not work without application modification. I think it is a real bug in logic. OK, if there is workaround for it? Yes, disabling session ticket via system property is a simple to use workaround. Then, will we fix the issue in the future? I think I'm OK if we have not plan to fix it in the future as the workaround is simple. So far, can we have an agreement that we will not fix the issue in the future? If we are still hesitate to make the decision, we might not want to push this CSR integration. If we have an agreement that we will not fix the issue in the future, we can close the bug as "Will not fix". I don't like the idea it mark it as "fixed". So, we may be able to make the documentation clarification with a new RFE. Does it make sense to you all?
01-05-2024
Technically, bound values are still supported if you set the jdk.tls.server.enableSessionTicket system property to false (though that may be undesirable), and this change documents that. [~xuelei] Sure, we could have handled this as two separate issues, but I think there is enough of a paper trail with the CSR and the comments in this discussion, that there won't be any future confusion if we need to revisit the issue. Also, I think being more direct about what behavior is supported by the JDK SunJSSE implementation is more clear and helpful to developers than a more general "may or may not be supported by an implementation". Also, I think it is acceptable to change the behavior of an @implNote in an update release, as long as there was an approved CSR for that change, and it did not affect the specification. I believe the javadoc can also be updated, if necessary. [~darcy] can you comment on this?
30-04-2024
> The value of the fix is that it explains the SunJSSE-specific behavior that that deviates from the interpretation one would most likely have if they read the spec without the information. Literally, I'm not sure how much it will help the developers. It it is the purpose for future code, I may go with a way like: "While stateless session ticket is enabled, a provider may not retain or resume the bound values. Developers should double check the behavior of the provider from release to release, if one want to use stateless session ticket together with bound values." With some words like this, we may be able to make SunJSSE behavior change from 21.0.1 to JDK 21.0.3, without need to change the implNote in Java Doc. > I recall it being the subject of some lively discussion but it was not something we forgot to do, it was done that way on purpose. Yes, but we known there are bugs and we were not sure if it is worthy a fix at that time and hence filled this bug for tracking. If now we want to close this bug, it may mean it is not worthy a fix any longer.
30-04-2024
I think the intent was talking about major version numbers, like JDK 20 and JDK21 or something like that. Maybe I'm wrong, not sure. I can find that out. The value of the fix is that it explains the SunJSSE-specific behavior that that deviates from the interpretation one would most likely have if they read the spec without the information. It doesn't "fix" anything. From what I recall when the stateless session ticket feature was added not putting bound values into the session ticket was done intentionally because of various challenges (again, I point to Daniel Jelinski's analysis, but there are a couple other reasons I won't go into here). I recall it being the subject of some lively discussion but it was not something we forgot to do, it was done that way on purpose. In the scenario you describe if someone had to move 8 to 23 and we came up with a way to preserve the bound values, we would probably need another CSR regardless of whether there would be an implNote now. We would be making a behavioral change in SunJSSE from an existing behavior for SSLSession.getValue() that was in place since JDK 13 or 14, so at that time we'd document the change in behavior and remove this implNote (if it exists).
30-04-2024
> 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. I did not get it very clear about the meaning of 'versions" or "releases". JDK 21.0.3 and 21.0.1 are not the same release, right? I may be hesitate to change the behavior or API specification from 21.0.1 to JDK 21.0.3. It is not yet clear to me about the value to "fix" the bug with a doc clarification. This is a bug in logic, I think we both agree. If it is not a real bug in practice, no one care about the doc clarification. Otherwise, a doc clarification might be not sufficient to mitigate the compatibility issue. Suppose this CSR get approved and integrated into JDK 23.0.1, and one day, some complaint comes out and need a fix from JDK 8 to 23. What could we do next? Submit another CSR for JDK 23.0.3 to change the implNote? I'm not very sure if the process could be easy and what's the impact on applications build on JDK 23.0.1 implNote. It may be OK, but I was not comfortable to clarify a bug in the Java specification. > I do think your proposed solution, as I understand it, would introduce more - not less - variability into the API behavior. I agreed. But it is a kind of cost to address compatibility issues if existing. We could keep it simple if the compatibility issue is not serious. Anyway, if you have no plan to fix it, it may be nice to open a new RFE for doc clarification and close this bug as "will not fix". "Will not fix" could be easier to track and understand, comparing to "Fixed" status.
30-04-2024
[~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