Change in behaviour of SSLSessionContext APIs in recent Java 13 EA versions

[Anthony Scarpino]

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
>