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
