Possible bug in SSLEngine / SSLSession implementation

[Jamil Nimeh]

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.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20181212/eb2aaf84/attachment.htm>