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
