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

Anthony Scarpino anthony.scarpino at
Mon Jul 1 12:03:28 UTC 2019


Session ids can change due to the way the way stateless operates in the RFCs, particularly if a client doesn’t provide a session Id during resumption.  I can take a look at your test and let you know what I find. 



> On Jun 30, 2019, at 10:38 PM, Jaikiran Pai <jai.forums2013 at> wrote:
> It looks like there has been a change in behaviour in some of the APIs
> exposed by, 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]
> [2]
> -Jaikiran

More information about the security-dev mailing list