[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-security-dev
Subject:    Re: "Blocking operation" during SSLEngineImpl.unwrap()
From:       Norman Maurer <norman.maurer () googlemail ! com>
Date:       2020-08-24 13:50:14
Message-ID: E5FE1725-9718-4624-A17B-D0FF71974662 () googlemail ! com
[Download RAW message or body]

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@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


[prev in list] [next in list] [prev in thread] [next in thread]