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

[Jaikiran Pai]

Hello Tony,

On 01/07/19 10:28 PM, Anthony Scarpino wrote:
> 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.  

Thank you for looking into this and providing the details.


> 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.

Do you think the class-level as well as these method level javadoc of
the SSLSessionContext would need an update then? Right now the
class-level javadoc states:

<snip>

There are <code>SSLSessionContext</code> parameters that affect how
 * sessions are stored:
 * <UL>
 *      <LI>Sessions can be set to expire after a specified
 *      time limit.
 *      <LI>The number of sessions that can be stored in context
 *      can be limited.
 * </UL>
 * A session can be retrieved based on its session id, and all session id's
 * in a <code>SSLSessionContext</code> can be listed.

There's a mention about:

"Not all environments will contain session contexts."

but I take it as meaning that, not all environments will have the
SSLSessionContext instance itself rather than the SSLSession(s) that
this context holds.

The method level javadocs too don't make a mention that they may not
return the session ids or the SSLSession itself if the server/client is
configured to be stateless.

Also, do you think those system properties can be included in the
release notes to explain this change? I'm not familiar with what the
criteria is for adding to release notes, but I think adding this detail
might help quickly diagnose this change in behaviour.

-Jaikiran

>
> 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
>>
>