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

[Anthony Scarpino]

On 7/1/19 7:23 PM, Jaikiran Pai wrote:
> 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.

There are some javadoc changes, but maybe more will be needed.

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

The stateless feature will be in the release notes.

Tony

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