Not that I am aware of. I will look into it later this week again and report back.
Bye Norman > On 18. Aug 2020, at 02:21, Bradford Wetmore <bradford.wetm...@oracle.com> > wrote: > > > Hi Norman, > > There are a couple things in the stack trace that don't make sense. Am I > missing something? > > This looks like a server side trace, so the initialization of the > RandomCookie should be inside the Task for the FINISHED message consumption, > which kicks off the NewSessionTicket creation before ending. > > What version of the JDK is this stack trace from? I've looked at our current > code and have gone back to our initial TLSv1.3 changeset in jdk-11+20, and > I'm not seeing where the initialization of the RandomCookie could be done > outside of the FINISHED TASK processing. > > By chance is Netty replacing any of our sun.security.ssl.SSLEngine code? > > Here's what the code should look like. > > "MainThread" > at sun.security.ssl.SessionId.<init>(SessionId.java:45) > at > sun.security.ssl.NewSessionTicket$NewSessionTicketKickstartProducer.produce(NewSessionTicket.java:224) > at > sun.security.ssl.Finished$T13FinishedConsumer.onConsumeFinished(Finished.java:1134) > at > sun.security.ssl.Finished$T13FinishedConsumer.consume(Finished.java:877) > at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) > at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) > at > sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074) > at > sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) > at java.security.AccessController.doPrivileged(AccessController.java) > at > sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008) > at SSLEngineTemplate.runDelegatedTasks(SSLEngineTemplate.java:317) > at SSLEngineTemplate.runTest(SSLEngineTemplate.java:225) > at SSLEngineTemplate.main(SSLEngineTemplate.java:136) > > Thanks, > > Brad > > > On 8/7/2020 11:24 AM, Alan Bateman wrote: >> On 07/08/2020 18:27, Anthony Scarpino wrote: >>> Well if there were a bug it's with NativePRNG as the operation is suppose >>> to be non-blocking. Even so, /dev/urandom is nonblocking. The only reason >>> this looks to have been detected by the tool is because it's a blocking >>> read op. This all seems like an extremely unlikely situation. I don't see >>> this as something SSLEngine should be compensating for. >> Right, /dev/random is blocking, /dev/urandom is non-blocking. I just checked >> BlockHound and it seems to have the names of private methods in the java.io >> and java.net classes and I think instruments these methods on the assumption >> that they are blocking calls. The list seems to have been generated from an >> older JDK too, not really in sync with release JDK releases. So not clear to >> me that there is really an issue here. >> -Alan
