So is what I see something that should be fixed in general ? Like I said it does not matter if its TLSv1.3 or earlier.
Bye Norman > On 12. Dec 2018, at 15:42, Norman Maurer <norman.mau...@googlemail.com> wrote: > > 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 >> <mailto: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. >>> >>> >> >
