Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

Norman Maurer norman.maurer at googlemail.com
Thu Apr 2 13:57:26 UTC 2020


Thanks a lot… 

Happy to be able to help here.

Once you have a fix ready let me know and I can verify it with the netty testsuite.

Bye
Norman


> On 1. Apr 2020, at 23:37, Jamil Nimeh <jamil.j.nimeh at Oracle.Com> wrote:
> 
> Hi Norman, session context issue is here:
> 
> https://bugs.openjdk.java.net/browse/JDK-8242008 <https://bugs.openjdk.java.net/browse/JDK-8242008>
> --Jamil
> 
> On 4/1/2020 12:32 AM, Norman Maurer wrote:
>> Please add a link to the bug once it is created.
>> 
>> Bye
>> Norman
>> 
>> 
>>> On 31. Mar 2020, at 17:35, Jamil Nimeh <jamil.j.nimeh at Oracle.Com <mailto:jamil.j.nimeh at Oracle.Com>> wrote:
>>> 
>>> Thanks Norman, I'm going to file a bug on this one.  After playing with it a bit more I found cases where even SSLServerSockets do run into the issue but it doesn't always happen.  Still working on characterizing it.
>>> 
>>> --Jamil
>>> 
>>> On 3/31/2020 7:11 AM, Norman Maurer wrote:
>>>> Yes thats about right… if setting to false it works as expected.
>>>> 
>>>> 
>>>> Bye
>>>> Norman
>>>> 
>>>> 
>>>>> On 31. Mar 2020, at 01:50, Jamil Nimeh <jamil.j.nimeh at Oracle.Com <mailto:jamil.j.nimeh at Oracle.Com>> wrote:
>>>>> 
>>>>> Hi Norman,
>>>>> 
>>>>> I've been able to run your test code and I can reproduce it.  Interestingly enough, it appears to happen when -Djdk.tls.server.enableSessionTicketExtension=true, which is the default position.  With session tickets enabled, I would see the issue in TLS 1.3 and 1.2 connections just as you did.  Setting the above property to false however allowed me to make successful connections.  Would you mind setting that property to false, just to make sure you and I see the same thing?
>>>>> 
>>>>> I did go back and run SSLServerSocket-based connections just to see if the session ticket settings had any impact on things, but they don't.  I can make connections to a socket based SSL server regardless of the property value on the server side.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> --Jamil
>>>>> 
>>>>> On 3/30/2020 5:31 AM, Norman Maurer wrote:
>>>>>> Hey Sean,
>>>>>> 
>>>>>> There is not much to share as its just a simple handshake :)
>>>>>> 
>>>>>> Anyway here is a reproducer:
>>>>>> 
>>>>>> https://github.com/normanmaurer/jdk_ssl_session_context_reproducer <https://github.com/normanmaurer/jdk_ssl_session_context_reproducer>
>>>>>> 
>>>>>> It basically does nothing more then complete the handshake and then calling engine.getSession().getSessionContext() which will return null on the server side since JDK 14 (earlier versions work).
>>>>>> I tested it with TLSv1.2 and TLSv1.3 and both times it produced the error on JDK 14.
>>>>>> 
>>>>>> 
>>>>>> Bye
>>>>>> Norman
>>>>>> 
>>>>>> 
>>>>>>> On 30. Mar 2020, at 13:22, Seán Coffey <sean.coffey at oracle.com <mailto:sean.coffey at oracle.com>> wrote:
>>>>>>> 
>>>>>>> Looks interesting Norman. Do you want to share some more details about the peculiarities of this handshake before considering a fully fledged testcase ?
>>>>>>> 
>>>>>>> regards,
>>>>>>> Sean.
>>>>>>> 
>>>>>>> On 27/03/2020 12:48, Norman Maurer wrote:
>>>>>>>> Hi there,
>>>>>>>> 
>>>>>>>> I am just about to add JDK14 to the test matrix for netty and think I found a regression. Before I will invest time to write a standalone reproducer please let me know if you think this is a regression or not.
>>>>>>>> Basically after the handshake is complete SSLEngine.getSession().getSessionContext() returns null on the serverside when using JDK14. Running the same test with any previous version (JDK13 and earlier) doesn’t show the same result.
>>>>>>>> 
>>>>>>>> Does this sounds like a regression and if so should I provide a standalone reproducer here ?
>>>>>>>> 
>>>>>>>> Bye
>>>>>>>> Norman
>>>>>>>> 
>>>>>> 
>>>> 
>> 

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


More information about the security-dev mailing list