Hi,
You are correct this behavior is a result of stateless resumption. The
stateless servers does not keep session state information and is
currently opt-out. The system property
'jdk.tls.server.enableSessionTicketExtension' set to false will return
the server to stateful. The client side has a property also
'jdk.tls.client.enableSessionTicketExtension'.
So in the case of using getSession() and getIds(), stateless resumption
is one of the environments that session information is not available.
Tony
On 6/30/19 10:38 PM, Jaikiran Pai wrote:
It looks like there has been a change in behaviour in some of the APIs
exposed by javax.net.ssl.SSLSessionContext, in recent EA versions of
Java 13 (as well as latest upstream master). Before I proceed with the
details, I would like to credit Richard Opalka, from WildFly team, as
the person who originally noticed this due to its impact on WildFly
project[1]. What I have now done is narrow this down to a jtreg testcase
which reproduces this issue in a straightforward isolated code[2].
The issues appear (at least) in the
SSLSessionContext#getSession(sessionId) and SSLSessionContext#getIds().
Both these APIs no longer return the expected output. For example, the
SSLSessionContext#getSession(sessionId) returns null for a valid session
id and the SSLSessionContext#getIds() just returns no session ids.
The jtreg testcase in [2] opens a server over SSLSocket and a client
which just expects a reply from the server. The server when it accepts
the connection over the SSLSocket, gets hold of the SSLSession id from
that socket and then goes on to invoke the above APIs to try and get
hold of this information from the SSLSessionContext. This all works fine
on Java 8, 11, 12 and some versions of 13 EA, but fails in recent
versions of 13 as well as upstream master branch.
As Richard points out in [1], it seems related to certain stateless
session related changes in the JDK, but I don't have enough knowledge in
that area nor of the changes to understand if this change in behaviour
is expected or if this is genuinely a bug - hence decided to raise this
in the mailing list instead of filing a JBS.
[1] https://issues.jboss.org/browse/WFCORE-4532
[2] http://cr.openjdk.java.net/~jpai/webrev/sslsessioncontext/0/webrev/
-Jaikiran
