Hi Jamil, This was just noticed during a test which uses TLS1.2.
> On 12. Dec 2018, at 15:35, Jamil Nimeh <jamil.j.ni...@oracle.com> wrote: > > 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 >> <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. >> >> >
