Hi Norman, the new handshaker does return a new SSLSession object. Part
of JDK-8212885 fixes the lack of propagation of session values across
session objects, though that fix was largely in the context of TLS 1.3.
There is a backport set for it, but it is not yet complete as far as I'm
aware. Are you doing TLS 1.3 sessions? If so, are you able to try it
with the latest JDK?
One of the items we're going to be tacking soon is better TLS session
object management and new session ticket management so we can avoid
these value propagation issues in the future.
--Jamil
On 12/11/2018 11:59 PM, Norman Maurer wrote:
Hi all,
While working on some unit tests in netty I noticed that there may be
a bug in the JDK implementation of SSLEngine / SSLSession. If its not
a but it is at least surprising I would say.
So it seems like before the handshake all values that are set on the
SSLSession via putValue are shared across SSLEngine instances. Is this
by design or a bug ? I could not find anything I the java docs that
would tell me this is by design. It only states: "Until the initial
handshake has completed, this method returns a session object which
reports an invalid cipher suite of “SSL_NULL_WITH_NULL_NULL”. This
does not sound like it will be the same object every time and so it
would share the values.
You can find a reproducer which will throw an exception here:
https://github.com/normanmaurer/jdk_ssl_session_reproducer
I did reproduce this with the latest java8 and java11 releases but I
am almost sure it also exists in other versions.
