"Blocking operation" during SSLEngineImpl.unwrap()

[Bradford Wetmore]

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