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.ni...@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.ni...@oracle.com >>> <mailto:jamil.j.ni...@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.ni...@oracle.com >>>>> <mailto:jamil.j.ni...@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.cof...@oracle.com >>>>>>> <mailto:sean.cof...@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 >>>>>>>> >>>>>> >>>> >>
