"Blocking operation" during SSLEngineImpl.unwrap()

[Norman Maurer]

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