Re: [External] : Re: SSLEngine.unwrap on read-only input ByteBuffer

[Norman Maurer]

I agree with Chris here that doing in-place modification of the source buffer 
is really surprising even if it’s not read-only. This really sounds like 
something I would consider a „breaking change“ as I can’t imagine users would 
expect this at all (nothing was ever in the javadocs that would suggest this 
behavior)

Bye
Norman 

> Am 24.03.2022 um 21:32 schrieb Bradford Wetmore :
> 
> Problem easily duplicated, thanks for the reproducer.
> 
> I've updated the bug with the info.
> 
> Brad
> 
> 
>> On 3/24/2022 9:13 AM, Chris Vest wrote:
>> On Wed, Mar 23, 2022 at 10:38 AM Bradford Wetmore 
>> mailto:bradford.wetm...@oracle.com>> wrote:
>>Offhand, sounds like a bug to me.  I've filed:
>>https://bugs.openjdk.java.net/browse/JDK-8283577
>>
>> Thanks. The in-place use of the input buffer might also be unexpected even 
>> when the buffer is not read-only.
>>By chance, do you have a simple reproducer handy?
>> See https://github.com/netty/netty/pull/12213#issuecomment-1077796917 
>> 
>>Brad
>>On 3/23/2022 9:54 AM, Chris Vest wrote:
>> > Hi,
>> >
>> > In Netty we've been trying to design some safer APIs, and
>>attempted to
>> > make more use of read-only ByteBuffers.
>> >
>> > We discovered that SSLEngine.unwrap does not like read-only input
>> > buffers, even though the input buffers should in theory only be read
>> > from. We obviously make sure that the output buffers are writable.
>> >
>> > By my reading of the javadoc, and the code, I believe this was
>>intended
>> > to work - or at least not intended to not work - but probably wasn't
>> > tested directly.
>> >
>> > When we try we get this stack trace on adopt-openjdk-11.0.7:
>> >
>> > javax.net.ssl.SSLProtocolException: null
>> > at
>>java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129)
>> > at
>> > 
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:326)
>> > at
>> > 
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:269)
>> > at
>> > 
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
>> > at
>>java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:118)
>> > at
>> > 
>> java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:668)
>> > at
>> > 
>> java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:623)
>> > at
>> > 
>> java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:441)
>> > at
>> > 
>> java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:420)
>> > at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:674)
>> > at
>>io.netty5.handler.ssl.EngineWrapper.unwrap(EngineWrapper.java:100)
>> > at io.netty5.handler.ssl.SslHandler.unwrap(SslHandler.java:1227)
>> > at
>> > 
>> io.netty5.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1105)
>> > at io.netty5.handler.ssl.SslHandler.decode(SslHandler.java:1165)
>> > at
>> > 
>> io.netty5.handler.codec.ByteToMessageDecoderForBuffer.decodeRemovalReentryProtection(ByteToMessageDecoderForBuffer.java:384)
>> > at
>> > 
>> io.netty5.handler.codec.ByteToMessageDecoderForBuffer.callDecode(ByteToMessageDecoderForBuffer.java:327)
>> > ... 20 common frames omitted
>> > Caused by: java.nio.ReadOnlyBufferException: null
>> > at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2493)
>> > at
>> > 
>> java.base/sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1629)
>> > at
>> > 
>> java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240)
>> > at
>> > 
>> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197)
>> > at
>> > 
>> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160)
>> > at
>>java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
>> > ... 31 common frames omitted
>> >
>> >
>> > I also tried this on a panama-preview snapshot JDK I have, and got a
>> > similar stack trace:
>> >
>> > % java -version
>> > openjdk version "19-internal" 2022-09-20
>> > OpenJDK Runtime Environment (fastdebug build
>> > 19-internal-adhoc.chris.panama-foreign)
>> > OpenJDK 64-Bit Server VM (fastdebug build
>> > 19-internal-adhoc.chr

Re: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93)

[Norman Maurer]

On Fri, 23 Apr 2021 20:51:19 GMT, Alexey Bakhtin  wrote:

> Hello All,
> 
> Could you please review the fix for the JDK-8241248?
> The issue happens during the TLSv1.3 handshake without server stateless 
> session resumption in case of server receives several parallel requests with 
> the same pre_shared_key.
> The main idea of the fix is to remove resuming session from the session cache 
> in the early stage.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8241248
> Webrev: http://cr.openjdk.java.net/~abakhtin/8241248/webrev.v0/
> 
> The test from the bug report using OpenSSL is passed ( 
> -Djdk.tls.server.enableSessionTicketExtension=false )
> javax/net/ssl and sun/security/ssl jtreg tests passed
> 
> Regards
> Alexey

I can test this one with our netty testcase... Would also be good to have a 
testcase in openjdk tho

-

PR: https://git.openjdk.java.net/jdk/pull/3664

Re: [External] : Re: Bug with TLSv1.3 session resumption (most likely caused by concurrency bug)

[Norman Maurer]

Sorry for the noise but is there any update ? The bug makes it “impossible” for 
us to enable caching by default as it may cause issues on the remote peer which 
are hard to debug.

Bye
Norman


> On 19. Mar 2021, at 16:34, Jamil Nimeh  wrote:
> 
> Hi Norman, I've been working a couple other bugs, but I should have some time 
> to devote to it next week.
> 
> --Jamil
> 
> On 3/19/2021 6:15 AM, Norman Maurer wrote:
>> I was wondering if there is any update or anything I can help with ?
>> 
>> Bye
>> Norman 
>> 
>>> Am 04.03.2021 um 18:51 schrieb Jamil Nimeh  
>>> <mailto:jamil.j.ni...@oracle.com>:
>>> 
>>> 
>>> I already replied to Norman directly (because apparently I cannot seem to 
>>> find my Reply-all button before my morning caffeine!).  It does look quite 
>>> a bit like 8241248 and that issue is in my bug queue.  I haven't started 
>>> work on it yet, but now that Norman has provided me some links to a 
>>> reproducer I can give it a spin and see if I can make the bug happen 
>>> locally (Thanks Norman!)
>>> 
>>> --Jamil
>>> 
>>> On 3/4/2021 8:22 AM, Xue-Lei Fan wrote:
>>>> Forward to security-dev.
>>>> 
>>>> Xuelei
>>>> 
>>>>> On Mar 4, 2021, at 6:11 AM, Norman Maurer >>>> <mailto:norman.mau...@googlemail.com>> wrote:
>>>>> 
>>>>> Hi there,
>>>>> 
>>>>> I think I found a bug in the TLSv1.3 session cache implementation which 
>>>>> sometimes can cause failures during session resumption. 
>>>>> The cause of this sometimes show up as NPE:
>>>>> 
>>>>> javax.net.ssl.SSLException: Session has no PSK
>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>>>>> at 
>>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
>>>>> at 
>>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
>>>>> at 
>>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283)
>>>>> at 
>>>>> java.base/sun.security.ssl.PreSharedKeyExtension.checkBinder(PreSharedKeyExtension.java:537)
>>>>> at 
>>>>> java.base/sun.security.ssl.PreSharedKeyExtension$CHPreSharedKeyUpdate.consume(PreSharedKeyExtension.java:528)
>>>>> at 
>>>>> java.base/sun.security.ssl.SSLExtension.consumeOnTrade(SSLExtension.java:583)
>>>>> at 
>>>>> java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:222)
>>>>> at 
>>>>> java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:539)
>>>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
>>>>> at 
>>>>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234)
>>>>> at 
>>>>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170)
>>>>> at 
>>>>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
>>>>> at 
>>>>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
>>>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>>>>> at 
>>>>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
>>>>> at 
>>>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
>>>>> at 
>>>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
>>>>> at java.base/java.security.AccessController.doPrivileged(Native Method)
>>>>> at 
>>>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
>>>>> at 
>>>>> io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557)
>>>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571)
>>>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455)
>>>>> at 
>>>>> io.netty.handler.ssl.SslHandle

Re: Bug with TLSv1.3 session resumption (most likely caused by concurrency bug)

[Norman Maurer]

I was wondering if there is any update or anything I can help with ?

Bye
Norman 

> Am 04.03.2021 um 18:51 schrieb Jamil Nimeh :
> 
> 
> I already replied to Norman directly (because apparently I cannot seem to 
> find my Reply-all button before my morning caffeine!).  It does look quite a 
> bit like 8241248 and that issue is in my bug queue.  I haven't started work 
> on it yet, but now that Norman has provided me some links to a reproducer I 
> can give it a spin and see if I can make the bug happen locally (Thanks 
> Norman!)
> 
> --Jamil
> 
>> On 3/4/2021 8:22 AM, Xue-Lei Fan wrote:
>> Forward to security-dev.
>> 
>> Xuelei
>> 
>>> On Mar 4, 2021, at 6:11 AM, Norman Maurer  
>>> wrote:
>>> 
>>> Hi there,
>>> 
>>> I think I found a bug in the TLSv1.3 session cache implementation which 
>>> sometimes can cause failures during session resumption. 
>>> The cause of this sometimes show up as NPE:
>>> 
>>> javax.net.ssl.SSLException: Session has no PSK
>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>>> at 
>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
>>> at 
>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
>>> at 
>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283)
>>> at 
>>> java.base/sun.security.ssl.PreSharedKeyExtension.checkBinder(PreSharedKeyExtension.java:537)
>>> at 
>>> java.base/sun.security.ssl.PreSharedKeyExtension$CHPreSharedKeyUpdate.consume(PreSharedKeyExtension.java:528)
>>> at 
>>> java.base/sun.security.ssl.SSLExtension.consumeOnTrade(SSLExtension.java:583)
>>> at 
>>> java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:222)
>>> at 
>>> java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:539)
>>> at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
>>> at 
>>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234)
>>> at 
>>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170)
>>> at 
>>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
>>> at 
>>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
>>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>>> at 
>>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
>>> at 
>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
>>> at 
>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
>>> at java.base/java.security.AccessController.doPrivileged(Native Method)
>>> at 
>>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
>>> at 
>>> io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557)
>>> at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571)
>>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455)
>>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282)
>>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329)
>>> at 
>>> io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
>>> at 
>>> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
>>> at 
>>> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
>>> at 
>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>>> at 
>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
>>> at 
>>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
>>> at 
>>> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
>>> at 
>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>>> at 
>>> io.netty.channe

Bug with TLSv1.3 session resumption (most likely caused by concurrency bug)

[Norman Maurer]

Hi there,

I think I found a bug in the TLSv1.3 session cache implementation which 
sometimes can cause failures during session resumption. 
The cause of this sometimes show up as NPE:

javax.net.ssl.SSLException: Session has no PSK
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283)
at 
java.base/sun.security.ssl.PreSharedKeyExtension.checkBinder(PreSharedKeyExtension.java:537)
at 
java.base/sun.security.ssl.PreSharedKeyExtension$CHPreSharedKeyUpdate.consume(PreSharedKeyExtension.java:528)
at 
java.base/sun.security.ssl.SSLExtension.consumeOnTrade(SSLExtension.java:583)
at 
java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:222)
at 
java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:539)
at 
java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
at 
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234)
at 
java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170)
at 
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
at 
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
at 
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
at 
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
at 
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1074)
at 
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at 
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1008)
at 
io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1557)
at 
io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1571)
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1455)
at 
io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1282)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1329)
at 
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
at 
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at 
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at 
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at 
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at 
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:834)
java.lang.NullPointerException
at java.base/sun.security.ssl.HKDF.extract(HKDF.java:93)
at java.base/sun.security.ssl.HKDF.extract(HKDF.java:119)
at 
java.base/sun.security.ssl.ServerHello.setUpPskKD(ServerHello.java:1169)
at 
java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:547)
at 
java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)

Re: "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  
> 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.(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

Re: [TLS-backport8] Does TLSv1.3 work with www.google.com

[Norman Maurer]

Just FTW I think they still enable the TLS1.3 detection logic via their 
BoringSSL usage just like others noted:

https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_set_jdk11_workaround
 


Bye
Norman


> On 11. Aug 2020, at 04:23, Jamil Nimeh  wrote:
> 
> Hi Bernd,
> 
> Without seeing the respective traces it is hard to know for certain, but I 
> can tell you that BoringSSL looks for a specific "fingerprint" in the client 
> hello which it attributes to the original JDK 11 client hello.  They did this 
> to work around specific bugs in the initial TLS 1.3 implementation released 
> with JDK 11.
> 
> If the client hello is structured such that it doesn't match the fingerprint 
> then things proceed with no issues.  There are many ways to change the 
> fingerprint.  It can even be accomplished by using the identical set of 
> extensions that cause the failure, but ordering them differently.  I had more 
> than a few "WAT?" moments getting my head around that when we were 
> characterizing this issue back in April.  :)
> 
> If we were to look at the client hellos from that Zulu OpenJSSE provider, I'm 
> sure we could identify the element that changes the fingerprint such that it 
> works.
> 
> --Jamil
> 
> On 8/10/2020 7:10 PM, Bernd Eckenfels wrote:
>> Hello Jamil,
>> 
>> Thanks for responding, you are correct, this system property resolves my 
>> problem (on both the Oracle as well as Azure JRE).
>> 
>> There is however something fishy going on. With the OpenJSSE provider (as 
>> provided by Zulu) the default for this option seems to be =true, as the 
>> extension is sent in ClientHello. I naturally disabled it and I can see in 
>> the debug log that the extension is no longer requested - HOWEVER the 
>> handshake with google.com still succeeds with OpenJSSE. WAT? :)
>> 
>> Gruss
>> Bernd
>> 
>> 
>> --
>> http://bernd.eckenfels.net 
>> Von: security-dev  
>>  im Auftrag von Jamil Nimeh 
>>  
>> Gesendet: Tuesday, August 11, 2020 3:11:14 AM
>> An: security-dev@openjdk.java.net  
>>  
>> Betreff: Re: [TLS-backport8] Does TLSv1.3 work with www.google.com 
>> 
>>  
>> Hmmm, looks a lot like this issue: 
>> https://bugs.openjdk.java.net/browse/JDK-8241360 
>> .  What happens if you run 
>> it with -Djdk.tls.client.enableStatusRequestExtension=true?  That should get 
>> you past it.  This is mentioned in the release notes for 8u261:
>> 
>> https://www.oracle.com/java/technologies/javase/8u261-relnotes.html 
>> 
>> --Jamil
>> 
>> On 8/10/2020 5:49 PM, Bernd wrote:
>>> Hallo,
>>> 
>>> is the upcoming Java8u TLS backport supposed to work with 
>>> "-Djdk.tls.client.protocols=TLSv1.3" when connecting 
>>> tohttps://www.google.com ?
>>> 
>>> I get an alert when I try to HttpsURLConnection.open to it. This happens 
>>> with the Zulu port of this feature as well as the 8u261GA from Oracle. When 
>>> specifying TLSv1.3,TLSv1.2 it connects but uses a v2 cipher.
>>> 
>>> The OpenJSSE (-XX:+UseOpenJSSE) backport of Zulu seems not affected, it 
>>> does handshake correctly with Google (so only difference i can see is an 
>>> additional OCSP request and chacha cipher which is not picked).
>>> 
>>> javax.net.ssl|FINE|01|main|2020-08-11 01:45:23.268 
>>> CEST|Logger.java:765|Produced ClientHello handshake message (
>>> "ClientHello": {
>>>   "client version"  : "TLSv1.2",
>>>   "random"  : "51 1A 14 21 CF BA 47 06 AB 26 67 4C 97 D9 12 77 
>>> BA 61 93 E3 DE 61 5C AC 30 10 9A 82 42 3D FC F1",
>>>   "session id"  : "C7 34 0D C4 D4 14 43 12 32 80 CF 23 52 A5 44 7A 
>>> 34 4D BF F6 F0 62 4D 1F AA 3D 73 85 EB 49 29 B8",
>>>   "cipher suites"   : "[TLS_AES_128_GCM_SHA256(0x1301), 
>>> TLS_AES_256_GCM_SHA384(0x1302)]",
>>>   "compression methods" : "00",
>>>   "extensions"  : [
>>> "server_name (0)": {
>>>   type=host_name (0), value=www.google.com 
>>> },
>>> "supported_groups (10)": {
>>>   "versions": [secp256r1, secp384r1, secp521r1, ffdhe2048, ffdhe3072, 
>>> ffdhe4096, ffdhe6144, ffdhe8192]
>>> },
>>> "signature_algorithms (13)": {
>>>   "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, 
>>> ecdsa_secp521r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, 
>>> rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, 
>>> rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, 
>>> ecdsa_sha1, rsa_pkcs1_sha1]
>>> },
>>> "signature_algorithms_cert (50)": {
>>>   "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_s

Re: "Blocking operation" during SSLEngineImpl.unwrap()

[Norman Maurer]

I think the possibility that it may block should be enough to signal and so 
offload to a task.

If it never blocks then it’s not a bug... that’s why I asked the question in 
the first place .

Bye
Norman 
> Am 07.08.2020 um 18:13 schrieb Alan Bateman :
> 
> On 07/08/2020 16:00, Xuelei Fan wrote:
>> Hm, it's an interesting bug.  I filed the issue on the Java Bug System.
>>https://bugs.openjdk.java.net/browse/JDK-8251304
> It is a bug that a new random cookie is needed or it has from read from 
> /dev/urandom? I don't think the stack trace is enough to know if read is 
> really blocked.
> 
> -Alan

Re: "Blocking operation" during SSLEngineImpl.unwrap()

[Norman Maurer]

Thanks a lot… So seems like my assumption is correct then :)

Bye
Norman


> On 7. Aug 2020, at 17:00, Xuelei Fan  wrote:
> 
> Hm, it's an interesting bug.  I filed the issue on the Java Bug System.
>   https://bugs.openjdk.java.net/browse/JDK-8251304
> 
> Thanks,
> Xuelei
> 
> On 8/7/2020 5:00 AM, Norman Maurer wrote:
>> Hi there,
>> In netty we support using BlockHound[1] to detect if people do blocking 
>> operations within the EventLoop and so notify them that this should not be 
>> done. While running our integration tests with TLS1.3 we noticed that 
>> unwrap(…) may trigger an FileInputStream.read(…) which in theory could block 
>> for a long time. I was assuming that such an operation should only be done 
>> after SSLEngine.* returns NEED_TASK and so be delegated to another 
>> ThreadPool via getTask().
>> Now the question(s):
>> * Is my assumption incorrect ?
>> * If my assumption is correct should we fix this ?
>> Here is the stack trace when such a blocking call is detected:
>> reactor.blockhound.BlockingOperationError: Blocking call! 
>> java.io.FileInputStream#readBytes
>> at java.base/java.io.FileInputStream.readBytes(FileInputStream.java)
>> at java.base/java.io.FileInputStream.read(FileInputStream.java:273)
>> at java.base/java.io.FilterInputStream.read(FilterInputStream.java:133)
>> at 
>> java.base/sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:424)
>> at 
>> java.base/sun.security.provider.NativePRNG$RandomIO.ensureBufferValid(NativePRNG.java:526)
>> at 
>> java.base/sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:545)
>> at 
>> java.base/sun.security.provider.NativePRNG$NonBlocking.engineNextBytes(NativePRNG.java:318)
>> at java.base/java.security.SecureRandom.nextBytes(SecureRandom.java:741)
>> at java.base/sun.security.ssl.RandomCookie.(RandomCookie.java:67)
>> at java.base/sun.security.ssl.SessionId.(SessionId.java:45)
>> at 
>> java.base/sun.security.ssl.NewSessionTicket$NewSessionTicketKickstartProducer.produce(NewSessionTicket.java:225)
>> at 
>> java.base/sun.security.ssl.Finished$T13FinishedConsumer.onConsumeFinished(Finished.java:1100)
>> at 
>> java.base/sun.security.ssl.Finished$T13FinishedConsumer.consume(Finished.java:867)
>> at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>> at 
>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
>> at 
>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:418)
>> at 
>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:177)
>> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>> at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681)
>> at 
>> java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636)
>> at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454)
>> at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:433)
>> at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:634)
>> at 
>> io.netty.handler.ssl.SslHandler$SslEngineType$3.unwrap(SslHandler.java:282)
>> at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1380)
>> at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1275)
>> at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1322)
>> [1] https://github.com/reactor/BlockHound

"Blocking operation" during SSLEngineImpl.unwrap()

[Norman Maurer]

Hi there,

In netty we support using BlockHound[1] to detect if people do blocking 
operations within the EventLoop and so notify them that this should not be 
done. While running our integration tests with TLS1.3 we noticed that unwrap(…) 
may trigger an FileInputStream.read(…) which in theory could block for a long 
time. I was assuming that such an operation should only be done after 
SSLEngine.* returns NEED_TASK and so be delegated to another ThreadPool via 
getTask().

Now the question(s):

* Is my assumption incorrect ?
* If my assumption is correct should we fix this ?

Here is the stack trace when such a blocking call is detected:

reactor.blockhound.BlockingOperationError: Blocking call! 
java.io.FileInputStream#readBytes
at java.base/java.io.FileInputStream.readBytes(FileInputStream.java)
at java.base/java.io.FileInputStream.read(FileInputStream.java:273)
at java.base/java.io.FilterInputStream.read(FilterInputStream.java:133)
at 
java.base/sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:424)
at 
java.base/sun.security.provider.NativePRNG$RandomIO.ensureBufferValid(NativePRNG.java:526)
at 
java.base/sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:545)
at 
java.base/sun.security.provider.NativePRNG$NonBlocking.engineNextBytes(NativePRNG.java:318)
at java.base/java.security.SecureRandom.nextBytes(SecureRandom.java:741)
at java.base/sun.security.ssl.RandomCookie.(RandomCookie.java:67)
at java.base/sun.security.ssl.SessionId.(SessionId.java:45)
at 
java.base/sun.security.ssl.NewSessionTicket$NewSessionTicketKickstartProducer.produce(NewSessionTicket.java:225)
at 
java.base/sun.security.ssl.Finished$T13FinishedConsumer.onConsumeFinished(Finished.java:1100)
at 
java.base/sun.security.ssl.Finished$T13FinishedConsumer.consume(Finished.java:867)
at 
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
at 
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
at 
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:418)
at 
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:177)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
at 
java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681)
at 
java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636)
at 
java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454)
at 
java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:433)
at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:634)
at 
io.netty.handler.ssl.SslHandler$SslEngineType$3.unwrap(SslHandler.java:282)
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1380)
at 
io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1275)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1322)

[1] https://github.com/reactor/BlockHound

Re: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

[Norman Maurer]

Thanks a lot… 

Happy to be able to help here.

Once you have a fix ready let me know and I can verify it with the netty 
testsuite.

Bye
Norman


> On 1. Apr 2020, at 23:37, Jamil Nimeh  wrote:
> 
> Hi Norman, session context issue is here:
> 
> https://bugs.openjdk.java.net/browse/JDK-8242008 
> <https://bugs.openjdk.java.net/browse/JDK-8242008>
> --Jamil
> 
> On 4/1/2020 12:32 AM, Norman Maurer wrote:
>> Please add a link to the bug once it is created.
>> 
>> Bye
>> Norman
>> 
>> 
>>> On 31. Mar 2020, at 17:35, Jamil Nimeh >> <mailto:jamil.j.ni...@oracle.com>> wrote:
>>> 
>>> Thanks Norman, I'm going to file a bug on this one.  After playing with it 
>>> a bit more I found cases where even SSLServerSockets do run into the issue 
>>> but it doesn't always happen.  Still working on characterizing it.
>>> 
>>> --Jamil
>>> 
>>> On 3/31/2020 7:11 AM, Norman Maurer wrote:
>>>> Yes thats about right… if setting to false it works as expected.
>>>> 
>>>> 
>>>> Bye
>>>> Norman
>>>> 
>>>> 
>>>>> On 31. Mar 2020, at 01:50, Jamil Nimeh >>>> <mailto:jamil.j.ni...@oracle.com>> wrote:
>>>>> 
>>>>> Hi Norman,
>>>>> 
>>>>> I've been able to run your test code and I can reproduce it.  
>>>>> Interestingly enough, it appears to happen when 
>>>>> -Djdk.tls.server.enableSessionTicketExtension=true, which is the default 
>>>>> position.  With session tickets enabled, I would see the issue in TLS 1.3 
>>>>> and 1.2 connections just as you did.  Setting the above property to false 
>>>>> however allowed me to make successful connections.  Would you mind 
>>>>> setting that property to false, just to make sure you and I see the same 
>>>>> thing?
>>>>> 
>>>>> I did go back and run SSLServerSocket-based connections just to see if 
>>>>> the session ticket settings had any impact on things, but they don't.  I 
>>>>> can make connections to a socket based SSL server regardless of the 
>>>>> property value on the server side.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> --Jamil
>>>>> 
>>>>> On 3/30/2020 5:31 AM, Norman Maurer wrote:
>>>>>> Hey Sean,
>>>>>> 
>>>>>> There is not much to share as its just a simple handshake :)
>>>>>> 
>>>>>> Anyway here is a reproducer:
>>>>>> 
>>>>>> https://github.com/normanmaurer/jdk_ssl_session_context_reproducer 
>>>>>> <https://github.com/normanmaurer/jdk_ssl_session_context_reproducer>
>>>>>> 
>>>>>> It basically does nothing more then complete the handshake and then 
>>>>>> calling engine.getSession().getSessionContext() which will return null 
>>>>>> on the server side since JDK 14 (earlier versions work).
>>>>>> I tested it with TLSv1.2 and TLSv1.3 and both times it produced the 
>>>>>> error on JDK 14.
>>>>>> 
>>>>>> 
>>>>>> Bye
>>>>>> Norman
>>>>>> 
>>>>>> 
>>>>>>> On 30. Mar 2020, at 13:22, Seán Coffey >>>>>> <mailto:sean.cof...@oracle.com>> wrote:
>>>>>>> 
>>>>>>> Looks interesting Norman. Do you want to share some more details about 
>>>>>>> the peculiarities of this handshake before considering a fully fledged 
>>>>>>> testcase ?
>>>>>>> 
>>>>>>> regards,
>>>>>>> Sean.
>>>>>>> 
>>>>>>> On 27/03/2020 12:48, Norman Maurer wrote:
>>>>>>>> Hi there,
>>>>>>>> 
>>>>>>>> I am just about to add JDK14 to the test matrix for netty and think I 
>>>>>>>> found a regression. Before I will invest time to write a standalone 
>>>>>>>> reproducer please let me know if you think this is a regression or not.
>>>>>>>> Basically after the handshake is complete 
>>>>>>>> SSLEngine.getSession().getSessionContext() returns null on the 
>>>>>>>> serverside when using JDK14. Running the same test with any previous 
>>>>>>>> version (JDK13 and earlier) doesn’t show the same result.
>>>>>>>> 
>>>>>>>> Does this sounds like a regression and if so should I provide a 
>>>>>>>> standalone reproducer here ?
>>>>>>>> 
>>>>>>>> Bye
>>>>>>>> Norman
>>>>>>>> 
>>>>>> 
>>>> 
>> 

Re: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

[Norman Maurer]

Please add a link to the bug once it is created.

Bye
Norman


> On 31. Mar 2020, at 17:35, Jamil Nimeh  wrote:
> 
> Thanks Norman, I'm going to file a bug on this one.  After playing with it a 
> bit more I found cases where even SSLServerSockets do run into the issue but 
> it doesn't always happen.  Still working on characterizing it.
> 
> --Jamil
> 
> On 3/31/2020 7:11 AM, Norman Maurer wrote:
>> Yes thats about right… if setting to false it works as expected.
>> 
>> 
>> Bye
>> Norman
>> 
>> 
>>> On 31. Mar 2020, at 01:50, Jamil Nimeh >> <mailto:jamil.j.ni...@oracle.com>> wrote:
>>> 
>>> Hi Norman,
>>> 
>>> I've been able to run your test code and I can reproduce it.  Interestingly 
>>> enough, it appears to happen when 
>>> -Djdk.tls.server.enableSessionTicketExtension=true, which is the default 
>>> position.  With session tickets enabled, I would see the issue in TLS 1.3 
>>> and 1.2 connections just as you did.  Setting the above property to false 
>>> however allowed me to make successful connections.  Would you mind setting 
>>> that property to false, just to make sure you and I see the same thing?
>>> 
>>> I did go back and run SSLServerSocket-based connections just to see if the 
>>> session ticket settings had any impact on things, but they don't.  I can 
>>> make connections to a socket based SSL server regardless of the property 
>>> value on the server side.
>>> 
>>> Thanks,
>>> 
>>> --Jamil
>>> 
>>> On 3/30/2020 5:31 AM, Norman Maurer wrote:
>>>> Hey Sean,
>>>> 
>>>> There is not much to share as its just a simple handshake :)
>>>> 
>>>> Anyway here is a reproducer:
>>>> 
>>>> https://github.com/normanmaurer/jdk_ssl_session_context_reproducer 
>>>> <https://github.com/normanmaurer/jdk_ssl_session_context_reproducer>
>>>> 
>>>> It basically does nothing more then complete the handshake and then 
>>>> calling engine.getSession().getSessionContext() which will return null on 
>>>> the server side since JDK 14 (earlier versions work).
>>>> I tested it with TLSv1.2 and TLSv1.3 and both times it produced the error 
>>>> on JDK 14.
>>>> 
>>>> 
>>>> Bye
>>>> Norman
>>>> 
>>>> 
>>>>> On 30. Mar 2020, at 13:22, Seán Coffey >>>> <mailto:sean.cof...@oracle.com>> wrote:
>>>>> 
>>>>> Looks interesting Norman. Do you want to share some more details about 
>>>>> the peculiarities of this handshake before considering a fully fledged 
>>>>> testcase ?
>>>>> 
>>>>> regards,
>>>>> Sean.
>>>>> 
>>>>> On 27/03/2020 12:48, Norman Maurer wrote:
>>>>>> Hi there,
>>>>>> 
>>>>>> I am just about to add JDK14 to the test matrix for netty and think I 
>>>>>> found a regression. Before I will invest time to write a standalone 
>>>>>> reproducer please let me know if you think this is a regression or not.
>>>>>> Basically after the handshake is complete 
>>>>>> SSLEngine.getSession().getSessionContext() returns null on the 
>>>>>> serverside when using JDK14. Running the same test with any previous 
>>>>>> version (JDK13 and earlier) doesn’t show the same result.
>>>>>> 
>>>>>> Does this sounds like a regression and if so should I provide a 
>>>>>> standalone reproducer here ?
>>>>>> 
>>>>>> Bye
>>>>>> Norman
>>>>>> 
>>>> 
>> 

Re: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

[Norman Maurer]

Yes thats about right… if setting to false it works as expected.


Bye
Norman


> On 31. Mar 2020, at 01:50, Jamil Nimeh  wrote:
> 
> Hi Norman,
> 
> I've been able to run your test code and I can reproduce it.  Interestingly 
> enough, it appears to happen when 
> -Djdk.tls.server.enableSessionTicketExtension=true, which is the default 
> position.  With session tickets enabled, I would see the issue in TLS 1.3 and 
> 1.2 connections just as you did.  Setting the above property to false however 
> allowed me to make successful connections.  Would you mind setting that 
> property to false, just to make sure you and I see the same thing?
> 
> I did go back and run SSLServerSocket-based connections just to see if the 
> session ticket settings had any impact on things, but they don't.  I can make 
> connections to a socket based SSL server regardless of the property value on 
> the server side.
> 
> Thanks,
> 
> --Jamil
> 
> On 3/30/2020 5:31 AM, Norman Maurer wrote:
>> Hey Sean,
>> 
>> There is not much to share as its just a simple handshake :)
>> 
>> Anyway here is a reproducer:
>> 
>> https://github.com/normanmaurer/jdk_ssl_session_context_reproducer 
>> <https://github.com/normanmaurer/jdk_ssl_session_context_reproducer>
>> 
>> It basically does nothing more then complete the handshake and then calling 
>> engine.getSession().getSessionContext() which will return null on the server 
>> side since JDK 14 (earlier versions work).
>> I tested it with TLSv1.2 and TLSv1.3 and both times it produced the error on 
>> JDK 14.
>> 
>> 
>> Bye
>> Norman
>> 
>> 
>>> On 30. Mar 2020, at 13:22, Seán Coffey >> <mailto:sean.cof...@oracle.com>> wrote:
>>> 
>>> Looks interesting Norman. Do you want to share some more details about the 
>>> peculiarities of this handshake before considering a fully fledged testcase 
>>> ?
>>> 
>>> regards,
>>> Sean.
>>> 
>>> On 27/03/2020 12:48, Norman Maurer wrote:
>>>> Hi there,
>>>> 
>>>> I am just about to add JDK14 to the test matrix for netty and think I 
>>>> found a regression. Before I will invest time to write a standalone 
>>>> reproducer please let me know if you think this is a regression or not.
>>>> Basically after the handshake is complete 
>>>> SSLEngine.getSession().getSessionContext() returns null on the serverside 
>>>> when using JDK14. Running the same test with any previous version (JDK13 
>>>> and earlier) doesn’t show the same result.
>>>> 
>>>> Does this sounds like a regression and if so should I provide a standalone 
>>>> reproducer here ?
>>>> 
>>>> Bye
>>>> Norman
>>>> 
>> 

Re: Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

[Norman Maurer]

Hey Sean,

There is not much to share as its just a simple handshake :)

Anyway here is a reproducer:

https://github.com/normanmaurer/jdk_ssl_session_context_reproducer 
<https://github.com/normanmaurer/jdk_ssl_session_context_reproducer>

It basically does nothing more then complete the handshake and then calling 
engine.getSession().getSessionContext() which will return null on the server 
side since JDK 14 (earlier versions work).
I tested it with TLSv1.2 and TLSv1.3 and both times it produced the error on 
JDK 14.


Bye
Norman


> On 30. Mar 2020, at 13:22, Seán Coffey  wrote:
> 
> Looks interesting Norman. Do you want to share some more details about the 
> peculiarities of this handshake before considering a fully fledged testcase ?
> 
> regards,
> Sean.
> 
> On 27/03/2020 12:48, Norman Maurer wrote:
>> Hi there,
>> 
>> I am just about to add JDK14 to the test matrix for netty and think I found 
>> a regression. Before I will invest time to write a standalone reproducer 
>> please let me know if you think this is a regression or not.
>> Basically after the handshake is complete 
>> SSLEngine.getSession().getSessionContext() returns null on the serverside 
>> when using JDK14. Running the same test with any previous version (JDK13 and 
>> earlier) doesn’t show the same result.
>> 
>> Does this sounds like a regression and if so should I provide a standalone 
>> reproducer here ?
>> 
>> Bye
>> Norman
>> 

Possible regression in JDK 14 related to SSLSessionContext / SSLSession on the server side

[Norman Maurer]

Hi there,

I am just about to add JDK14 to the test matrix for netty and think I found a 
regression. Before I will invest time to write a standalone reproducer please 
let me know if you think this is a regression or not.
Basically after the handshake is complete 
SSLEngine.getSession().getSessionContext() returns null on the serverside when 
using JDK14. Running the same test with any previous version (JDK13 and 
earlier) doesn’t show the same result.

Does this sounds like a regression and if so should I provide a standalone 
reproducer here ?

Bye
Norman

Re: Possible bug with JDK12 and ChaCha ciphers

[Norman Maurer]

Hi there,


Did the debug log help at all or should I try to gather more informations from 
the user ?

Bye
Norman


> On 17. May 2019, at 21:26, Norman Maurer  wrote:
> 
> The user did capture the log here:
> 
> https://hasteb.in/ucalevob.makefile <https://hasteb.in/ucalevob.makefile>
> 
> Hopefully it is helpful,
> 
> Norman
> 
> 
>> On 17. May 2019, at 20:38, Norman Maurer > <mailto:norman.mau...@googlemail.com>> wrote:
>> 
>> Unfortunately I am very busy atm so it may take me a few days. I asked the 
>> original reported of the issue to provide some in the netty issue tracker. I 
>> will come back to you.
>> 
>> Bye
>> Norman
>> 
>> 
>>> On 17. May 2019, at 20:27, Xuelei Fan >> <mailto:xuelei@oracle.com>> wrote:
>>> 
>>> Hi Norman,
>>> 
>>> If you are able to reproduce this issue, would you mind post the JSSE debug 
>>> log (by using Java System Property, "javax.net.debug=all")?
>>> 
>>> Please feel free to submit a bug.
>>> 
>>> Thanks & Regards,
>>> Xuelei
>>> 
>>> On 5/17/2019 11:02 AM, Norman Maurer wrote:
>>>> Hi there,
>>>> We recently received a bug report in netty when JDK12 is used with ChaCha 
>>>> chiphers:
>>>> https://github.com/netty/netty/issues/9150 
>>>> <https://github.com/netty/netty/issues/9150>
>>>> Basically it seems like there is a problem in how it uses the ByteBuffer 
>>>> internally:
>>>> |Caused by: java.lang.RuntimeException: javax.crypto.ShortBufferException: 
>>>> Output buffer too small at 
>>>> java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:703)
>>>>  at java.base/javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:826) at 
>>>> java.base/javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730) at 
>>>> java.base/javax.crypto.Cipher.doFinal(Cipher.java:2503) at 
>>>> java.base/sun.security.ssl.SSLCipher$T12CC20P1305ReadCipherGenerator$CC20P1305ReadCipher.decrypt(SSLCipher.java:2188)
>>>>  at 
>>>> java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240)
>>>>  at 
>>>> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197)
>>>>  at 
>>>> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160)
>>>>  at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) 
>>>> at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) 
>>>> at 
>>>> java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636)
>>>>  at 
>>>> java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) 
>>>> ... 25 common frames omitted Caused by: javax.crypto.ShortBufferException: 
>>>> Output buffer too small at 
>>>> java.base/com.sun.crypto.provider.ChaCha20Cipher$EngineAEADDec.doFinal(ChaCha20Cipher.java:1360)
>>>>  at 
>>>> java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:701)|
>>>> Unfortunately I have no standalone reproducer yet but I just wanted to 
>>>> bring it up here in case it helps.
>>>> It only happens on JDK12 it seems. Check the Netty issue for more details…
>>>> Bye
>>>> Norman
>> 
> 

Re: Possible bug with JDK12 and ChaCha ciphers

[Norman Maurer]

The user did capture the log here:

https://hasteb.in/ucalevob.makefile <https://hasteb.in/ucalevob.makefile>

Hopefully it is helpful,

Norman


> On 17. May 2019, at 20:38, Norman Maurer  wrote:
> 
> Unfortunately I am very busy atm so it may take me a few days. I asked the 
> original reported of the issue to provide some in the netty issue tracker. I 
> will come back to you.
> 
> Bye
> Norman
> 
> 
>> On 17. May 2019, at 20:27, Xuelei Fan  wrote:
>> 
>> Hi Norman,
>> 
>> If you are able to reproduce this issue, would you mind post the JSSE debug 
>> log (by using Java System Property, "javax.net.debug=all")?
>> 
>> Please feel free to submit a bug.
>> 
>> Thanks & Regards,
>> Xuelei
>> 
>> On 5/17/2019 11:02 AM, Norman Maurer wrote:
>>> Hi there,
>>> We recently received a bug report in netty when JDK12 is used with ChaCha 
>>> chiphers:
>>> https://github.com/netty/netty/issues/9150
>>> Basically it seems like there is a problem in how it uses the ByteBuffer 
>>> internally:
>>> |Caused by: java.lang.RuntimeException: javax.crypto.ShortBufferException: 
>>> Output buffer too small at 
>>> java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:703)
>>>  at java.base/javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:826) at 
>>> java.base/javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730) at 
>>> java.base/javax.crypto.Cipher.doFinal(Cipher.java:2503) at 
>>> java.base/sun.security.ssl.SSLCipher$T12CC20P1305ReadCipherGenerator$CC20P1305ReadCipher.decrypt(SSLCipher.java:2188)
>>>  at 
>>> java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240)
>>>  at 
>>> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197)
>>>  at 
>>> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160)
>>>  at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) 
>>> at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) 
>>> at 
>>> java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636) 
>>> at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) 
>>> ... 25 common frames omitted Caused by: javax.crypto.ShortBufferException: 
>>> Output buffer too small at 
>>> java.base/com.sun.crypto.provider.ChaCha20Cipher$EngineAEADDec.doFinal(ChaCha20Cipher.java:1360)
>>>  at 
>>> java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:701)|
>>> Unfortunately I have no standalone reproducer yet but I just wanted to 
>>> bring it up here in case it helps.
>>> It only happens on JDK12 it seems. Check the Netty issue for more details…
>>> Bye
>>> Norman
> 

Re: Possible bug with JDK12 and ChaCha ciphers

[Norman Maurer]

Unfortunately I am very busy atm so it may take me a few days. I asked the 
original reported of the issue to provide some in the netty issue tracker. I 
will come back to you.

Bye
Norman


> On 17. May 2019, at 20:27, Xuelei Fan  wrote:
> 
> Hi Norman,
> 
> If you are able to reproduce this issue, would you mind post the JSSE debug 
> log (by using Java System Property, "javax.net.debug=all")?
> 
> Please feel free to submit a bug.
> 
> Thanks & Regards,
> Xuelei
> 
> On 5/17/2019 11:02 AM, Norman Maurer wrote:
>> Hi there,
>> We recently received a bug report in netty when JDK12 is used with ChaCha 
>> chiphers:
>> https://github.com/netty/netty/issues/9150
>> Basically it seems like there is a problem in how it uses the ByteBuffer 
>> internally:
>> |Caused by: java.lang.RuntimeException: javax.crypto.ShortBufferException: 
>> Output buffer too small at 
>> java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:703)
>>  at java.base/javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:826) at 
>> java.base/javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730) at 
>> java.base/javax.crypto.Cipher.doFinal(Cipher.java:2503) at 
>> java.base/sun.security.ssl.SSLCipher$T12CC20P1305ReadCipherGenerator$CC20P1305ReadCipher.decrypt(SSLCipher.java:2188)
>>  at 
>> java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240)
>>  at 
>> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197)
>>  at 
>> java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160)
>>  at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) at 
>> java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681) at 
>> java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636) 
>> at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454) 
>> ... 25 common frames omitted Caused by: javax.crypto.ShortBufferException: 
>> Output buffer too small at 
>> java.base/com.sun.crypto.provider.ChaCha20Cipher$EngineAEADDec.doFinal(ChaCha20Cipher.java:1360)
>>  at 
>> java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:701)|
>> Unfortunately I have no standalone reproducer yet but I just wanted to bring 
>> it up here in case it helps.
>> It only happens on JDK12 it seems. Check the Netty issue for more details…
>> Bye
>> Norman

Possible bug with JDK12 and ChaCha ciphers

[Norman Maurer]

Hi there,

We recently received a bug report in netty when JDK12 is used with ChaCha 
chiphers:

https://github.com/netty/netty/issues/9150 


Basically it seems like there is a problem in how it uses the ByteBuffer 
internally:


Caused by: java.lang.RuntimeException: javax.crypto.ShortBufferException: 
Output buffer too small
at 
java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:703)
at java.base/javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:826)
at java.base/javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730)
at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2503)
at 
java.base/sun.security.ssl.SSLCipher$T12CC20P1305ReadCipherGenerator$CC20P1305ReadCipher.decrypt(SSLCipher.java:2188)
at 
java.base/sun.security.ssl.SSLEngineInputRecord.decodeInputRecord(SSLEngineInputRecord.java:240)
at 
java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:197)
at 
java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:160)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
at 
java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681)
at 
java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636)
at 
java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454)
... 25 common frames omitted
Caused by: javax.crypto.ShortBufferException: Output buffer too small
at 
java.base/com.sun.crypto.provider.ChaCha20Cipher$EngineAEADDec.doFinal(ChaCha20Cipher.java:1360)
at 
java.base/com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal(ChaCha20Cipher.java:701)


Unfortunately I have no standalone reproducer yet but I just wanted to bring it 
up here in case it helps.

It only happens on JDK12 it seems. Check the Netty issue for more details…


Bye
Norman

Re: Use of OpenSSL as JCE security provider if available on system

[Norman Maurer]

Actually this is not based on OpenSSL but it uses BoringSSL (which provides an 
OpenSSL API + some extra stuff), just in case it matters for anyone.

Bye
Norman


> On 15. Mar 2019, at 17:37, Simone Bordet  wrote:
> 
> Hi,
> 
> On Fri, Mar 15, 2019 at 3:28 PM Darran Lofthouse
>  wrote:
>> FYI if anyone is interested in using OpenSSL through a Java security 
>> Provider we have this project available within the WildFly project: -
>> 
>> https://github.com/wildfly/wildfly-openssl
> 
> There is also the effort from Google, Conscrypt:
> https://github.com/google/conscrypt
> 
> It's a full blown JCE and JSSE implementation based on OpenSSL, so it
> can easily be used in this way;
> 
> java.security.Security.addProvider(new org.conscrypt.OpenSSLProvider());
> 
> To my knowledge, Conscrypt is what's being used in Android and we
> optionally use it in Jetty too.
> 
> -- 
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz

Re: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

[Norman Maurer]

I assumed that it should return NEED_UNWRAP if there is something left that 
needs to be consumed (that’s also what happened in JDK11 and before).

How should we know then that there is an alert to consume ?

Bye
Norman

> Am 13.03.2019 um 15:11 schrieb Xuelei Fan :
> 
> Hi Norman,
> 
> What's the problem in the application?  It is possible that status is 
> NOT_HANDSHAKING even there are bytes left that should be consumed, for 
> example alert or application data.  NOT_HANDSHAKING means that the 
> handshaking is not in progress.
> 
> Thanks,
> Xuelei
> 
>> On 2/28/2019 12:24 AM, Norman Maurer wrote:
>> Hi all,
>> I think I found a possible regression / bug in the latest JDK12 release when 
>> trying to upgrade the Netty CI server to test with the latest JDK12 release. 
>> The problem is that SSLEngine.wrap(…) returns NOT_HANDSHAKING even when 
>> there are bytes left that should be consumed (the alert itself). My 
>> understanding is that it should only return “NOT_HANDSHAKING” once we also 
>> consumed the alert. Please correct me if I wrong tho.
>> I pushed a reproducer for this here:
>> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug
>> When running this on the latest JDK12 release (and later JDK versions) it 
>> will fail with an AssertionError, while everything works as expected when 
>> using earlier Java versions.
>> Here is the Java version I used to reproduce:
>> # java -version
>> openjdk version "12" 2019-03-19
>> OpenJDK Runtime Environment (build 12+33)
>> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)
>> It seems like this was not always the case for Java12 tho, as I can not 
>> reproduce it with this version:
>> #java -version
>> openjdk version "12-ea" 2019-03-19
>> OpenJDK Runtime Environment (build 12-ea+27)
>> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing)
>> I don't have all the “in between” releases on my machine atm so I can not 
>> tell exactly on which release this “broke” :/
>> Thanks
>> Norman

Re: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

[Norman Maurer]

atedTask();
if (task == null) {
break;
}
task.run();
}
}
}


private static void assertTrue(boolean result) {
if (!result) {
throw new AssertionError();
}
}

private static void assertFalse(boolean result) {
if (result) {
throw new AssertionError();
}
}

private static void assertEquals(Object o1, Object o2) {
if (!o1.equals(o2)) {
throw new AssertionError(o1 + " != " + o2);
}
    }
}


> On 13. Mar 2019, at 10:04, Alan Bateman  wrote:
> 
> On 13/03/2019 07:51, Norman Maurer wrote:
>> As it contains also keymaterial can I just tar it or will you be able to use 
>> your own keymaterial and fill in the missing pieces?
> If it's needed to demonstrate the issue then include but if it's just setup 
> then it would be better to provide the instructions. I don't know file types 
> are stripped by the mail servers but if you cc me then I can create an issue 
> in JBS.
> 
> -Alan

Re: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

[Norman Maurer]

Wasn’t it possible at some point to browse the bugs without a login ? When I 
try to look at the issue it asks me for a login :/

Bye
Norman


> On 13. Mar 2019, at 13:31, Sean Mullan  wrote:
> 
> My best guess is that https://bugs.openjdk.java.net/browse/JDK-8214418 is the 
> cause.
> 
> Xuelei, would you have time to look at this?
> 
> Thanks,
> Sean
> 
> On 3/13/19 2:31 AM, Norman Maurer wrote:
>> Is there anything else I can do to have anyone look into this?
>> I just want to make sure this does not fall through before the final JDK 12 
>> release is done.
>> Bye
>> Norman
>>> On 4. Mar 2019, at 21:15, Norman Maurer >> <mailto:norman.mau...@googlemail.com>> wrote:
>>> 
>>> Any comments here ?
>>> 
>>> Bye
>>> Norman
>>> 
>>> 
>>>> On 28. Feb 2019, at 09:24, Norman Maurer >>> <mailto:norman.mau...@googlemail.com>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I think I found a possible regression / bug in the latest JDK12 release 
>>>> when trying to upgrade the Netty CI server to test with the latest JDK12 
>>>> release. The problem is that SSLEngine.wrap(…) returns NOT_HANDSHAKING 
>>>> even when there are bytes left that should be consumed (the alert itself). 
>>>> My understanding is that it should only return “NOT_HANDSHAKING” once we 
>>>> also consumed the alert. Please correct me if I wrong tho.
>>>> 
>>>> I pushed a reproducer for this here:
>>>> 
>>>> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug
>>>> 
>>>> When running this on the latest JDK12 release (and later JDK versions) it 
>>>> will fail with an AssertionError, while everything works as expected when 
>>>> using earlier Java versions.
>>>> 
>>>> Here is the Java version I used to reproduce:
>>>> 
>>>> # java -version
>>>> openjdk version "12" 2019-03-19
>>>> OpenJDK Runtime Environment (build 12+33)
>>>> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)
>>>> 
>>>> 
>>>> It seems like this was not always the case for Java12 tho, as I can not 
>>>> reproduce it with this version:
>>>> 
>>>> #java -version
>>>> openjdk version "12-ea" 2019-03-19
>>>> OpenJDK Runtime Environment (build 12-ea+27)
>>>> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing)
>>>> 
>>>> I don't have all the “in between” releases on my machine atm so I can not 
>>>> tell exactly on which release this “broke” :/
>>>> 
>>>> Thanks
>>>> Norman
>>>> 
>>>> 
>>>> 
>>> 

Re: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

[Norman Maurer]

As it contains also keymaterial can I just tar it or will you be able to use 
your own keymaterial and fill in the missing pieces?

Bye
Norman


> On 13. Mar 2019, at 08:48, Alan Bateman  wrote:
> 
> On 13/03/2019 06:31, Norman Maurer wrote:
>> Is there anything else I can do to have anyone look into this?
>> 
>> I just want to make sure this does not fall through before the final JDK 12 
>> release is done.
>> 
> Can you attach or inline the test that demonstrates the issue you are seeing? 
> (we can't use reproducers that are hosted on github).
> 
> -Alan.

Re: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

[Norman Maurer]

Is there anything else I can do to have anyone look into this? 

I just want to make sure this does not fall through before the final JDK 12 
release is done. 

Bye
Norman


> On 4. Mar 2019, at 21:15, Norman Maurer  wrote:
> 
> Any comments here ?
> 
> Bye
> Norman
> 
> 
>> On 28. Feb 2019, at 09:24, Norman Maurer > <mailto:norman.mau...@googlemail.com>> wrote:
>> 
>> Hi all,
>> 
>> I think I found a possible regression / bug in the latest JDK12 release when 
>> trying to upgrade the Netty CI server to test with the latest JDK12 release. 
>> The problem is that SSLEngine.wrap(…) returns NOT_HANDSHAKING even when 
>> there are bytes left that should be consumed (the alert itself). My 
>> understanding is that it should only return “NOT_HANDSHAKING” once we also 
>> consumed the alert. Please correct me if I wrong tho.
>> 
>> I pushed a reproducer for this here:
>> 
>> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug 
>> <https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug>
>> 
>> When running this on the latest JDK12 release (and later JDK versions) it 
>> will fail with an AssertionError, while everything works as expected when 
>> using earlier Java versions.
>> 
>> Here is the Java version I used to reproduce:
>> 
>> # java -version
>> openjdk version "12" 2019-03-19
>> OpenJDK Runtime Environment (build 12+33)
>> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)
>> 
>> 
>> It seems like this was not always the case for Java12 tho, as I can not 
>> reproduce it with this version:
>> 
>> #java -version
>> openjdk version "12-ea" 2019-03-19
>> OpenJDK Runtime Environment (build 12-ea+27)
>> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing)
>> 
>> I don't have all the “in between” releases on my machine atm so I can not 
>> tell exactly on which release this “broke” :/
>> 
>> Thanks
>> Norman
>> 
>> 
>> 
> 

Re: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

[Norman Maurer]

Any comments here ?

Bye
Norman


> On 28. Feb 2019, at 09:24, Norman Maurer  wrote:
> 
> Hi all,
> 
> I think I found a possible regression / bug in the latest JDK12 release when 
> trying to upgrade the Netty CI server to test with the latest JDK12 release. 
> The problem is that SSLEngine.wrap(…) returns NOT_HANDSHAKING even when there 
> are bytes left that should be consumed (the alert itself). My understanding 
> is that it should only return “NOT_HANDSHAKING” once we also consumed the 
> alert. Please correct me if I wrong tho.
> 
> I pushed a reproducer for this here:
> 
> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug 
> <https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug>
> 
> When running this on the latest JDK12 release (and later JDK versions) it 
> will fail with an AssertionError, while everything works as expected when 
> using earlier Java versions.
> 
> Here is the Java version I used to reproduce:
> 
> # java -version
> openjdk version "12" 2019-03-19
> OpenJDK Runtime Environment (build 12+33)
> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)
> 
> 
> It seems like this was not always the case for Java12 tho, as I can not 
> reproduce it with this version:
> 
> #java -version
> openjdk version "12-ea" 2019-03-19
> OpenJDK Runtime Environment (build 12-ea+27)
> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing)
> 
> I don't have all the “in between” releases on my machine atm so I can not 
> tell exactly on which release this “broke” :/
> 
> Thanks
> Norman
> 
> 
> 

SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was not consumed yet in latest JDK12 release (possible regression).

[Norman Maurer]

Hi all,

I think I found a possible regression / bug in the latest JDK12 release when 
trying to upgrade the Netty CI server to test with the latest JDK12 release. 
The problem is that SSLEngine.wrap(…) returns NOT_HANDSHAKING even when there 
are bytes left that should be consumed (the alert itself). My understanding is 
that it should only return “NOT_HANDSHAKING” once we also consumed the alert. 
Please correct me if I wrong tho.

I pushed a reproducer for this here:

https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug 


When running this on the latest JDK12 release (and later JDK versions) it will 
fail with an AssertionError, while everything works as expected when using 
earlier Java versions.

Here is the Java version I used to reproduce:

# java -version
openjdk version "12" 2019-03-19
OpenJDK Runtime Environment (build 12+33)
OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)


It seems like this was not always the case for Java12 tho, as I can not 
reproduce it with this version:

#java -version
openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment (build 12-ea+27)
OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing)

I don't have all the “in between” releases on my machine atm so I can not tell 
exactly on which release this “broke” :/

Thanks
Norman

Re: Possible bug in SSLEngine / SSLSession implementation

[Norman Maurer]

So is what I see something that should be fixed in general ?

Like I said it does not matter if its TLSv1.3 or earlier.

Bye
Norman


> On 12. Dec 2018, at 15:42, Norman Maurer  wrote:
> 
> Hi Jamil,
> 
> This was just noticed during a test which uses TLS1.2. 
> 
>> On 12. Dec 2018, at 15:35, Jamil Nimeh > <mailto:jamil.j.ni...@oracle.com>> wrote:
>> 
>> Hi Norman, the new handshaker does return a new SSLSession object.  Part of 
>> JDK-8212885 fixes the lack of propagation of session values across session 
>> objects, though that fix was largely in the context of TLS 1.3.  There is a 
>> backport set for it, but it is not yet complete as far as I'm aware.  Are 
>> you doing TLS 1.3 sessions?  If so, are you able to try it with the latest 
>> JDK?
>> 
>> One of the items we're going to be tacking soon is better TLS session object 
>> management and new session ticket management so we can avoid these value 
>> propagation issues in the future.
>> 
>> --Jamil
>> 
>> On 12/11/2018 11:59 PM, Norman Maurer wrote:
>>> Hi all,
>>> 
>>> While working on some unit tests in netty I noticed that there may be a bug 
>>> in the JDK implementation of SSLEngine / SSLSession. If its not a but it is 
>>> at least surprising I would say.
>>> 
>>> 
>>> So it seems like before the handshake all values that are set on the 
>>> SSLSession via putValue are shared across SSLEngine instances. Is this by 
>>> design or a bug ? I could not find anything I the java docs that would tell 
>>> me this is by design. It only states: "Until the initial handshake has 
>>> completed, this method returns a session object which reports an invalid 
>>> cipher suite of “SSL_NULL_WITH_NULL_NULL”. This does not sound like it will 
>>> be the same object every time and so it would share the values.
>>> 
>>> You can find a reproducer which will throw an exception here:
>>> 
>>> https://github.com/normanmaurer/jdk_ssl_session_reproducer 
>>> <https://github.com/normanmaurer/jdk_ssl_session_reproducer>
>>> 
>>> 
>>> I did reproduce this with the latest java8 and java11 releases but I am 
>>> almost sure it also exists in other versions.
>>> 
>>> 
>> 
> 

Re: Possible bug in SSLEngine / SSLSession implementation

[Norman Maurer]

Hi Jamil,

This was just noticed during a test which uses TLS1.2. 

> On 12. Dec 2018, at 15:35, Jamil Nimeh  wrote:
> 
> Hi Norman, the new handshaker does return a new SSLSession object.  Part of 
> JDK-8212885 fixes the lack of propagation of session values across session 
> objects, though that fix was largely in the context of TLS 1.3.  There is a 
> backport set for it, but it is not yet complete as far as I'm aware.  Are you 
> doing TLS 1.3 sessions?  If so, are you able to try it with the latest JDK?
> 
> One of the items we're going to be tacking soon is better TLS session object 
> management and new session ticket management so we can avoid these value 
> propagation issues in the future.
> 
> --Jamil
> 
> On 12/11/2018 11:59 PM, Norman Maurer wrote:
>> Hi all,
>> 
>> While working on some unit tests in netty I noticed that there may be a bug 
>> in the JDK implementation of SSLEngine / SSLSession. If its not a but it is 
>> at least surprising I would say.
>> 
>> 
>> So it seems like before the handshake all values that are set on the 
>> SSLSession via putValue are shared across SSLEngine instances. Is this by 
>> design or a bug ? I could not find anything I the java docs that would tell 
>> me this is by design. It only states: "Until the initial handshake has 
>> completed, this method returns a session object which reports an invalid 
>> cipher suite of “SSL_NULL_WITH_NULL_NULL”. This does not sound like it will 
>> be the same object every time and so it would share the values.
>> 
>> You can find a reproducer which will throw an exception here:
>> 
>> https://github.com/normanmaurer/jdk_ssl_session_reproducer 
>> <https://github.com/normanmaurer/jdk_ssl_session_reproducer>
>> 
>> 
>> I did reproduce this with the latest java8 and java11 releases but I am 
>> almost sure it also exists in other versions.
>> 
>> 
> 

Possible bug in SSLEngine / SSLSession implementation

[Norman Maurer]

Hi all,

While working on some unit tests in netty I noticed that there may be a bug in 
the JDK implementation of SSLEngine / SSLSession. If its not a but it is at 
least surprising I would say.


So it seems like before the handshake all values that are set on the SSLSession 
via putValue are shared across SSLEngine instances. Is this by design or a bug 
? I could not find anything I the java docs that would tell me this is by 
design. It only states: "Until the initial handshake has completed, this method 
returns a session object which reports an invalid cipher suite of 
“SSL_NULL_WITH_NULL_NULL”. This does not sound like it will be the same object 
every time and so it would share the values.

You can find a reproducer which will throw an exception here:

https://github.com/normanmaurer/jdk_ssl_session_reproducer 



I did reproduce this with the latest java8 and java11 releases but I am almost 
sure it also exists in other versions.

Re: java.lang.NoSuchFieldError: state

[Norman Maurer]

I think this may be caused by using the wrong jetty alpn version.

Be sure you use the correct one. For example 2.0.9:

https://github.com/jetty-project/jetty-alpn-agent/releases 


Bye
Norman


> On 6. Nov 2018, at 07:46, Martin Choma  wrote:
> 
> Hey,
> 
> with upgrade to 1.8.0_191 I hit "java.lang.NoSuchFieldError: state"
> during SSL handshake.
> I have found https://bugs.java.com/view_bug.do?bug_id=JDK-8074462 but
> I couldn find openjdk counterpart. Some more details can be found [1].
> 
> Regards,
> Martin Choma
> 
> [1] https://issues.jboss.org/browse/ELY-1708

Re: RFR[s] 8211339: NPE during SSL handshake caused by HostnameChecker

[Norman Maurer]

LGTM as well… thanks a lot!


> On 5. Nov 2018, at 20:22, Xuelei Fan  wrote:
> 
> It looks fine to me.
> 
> Thanks,
> Xuelei
> 
> On 11/5/2018 10:59 AM, Anthony Scarpino wrote:
>> Hi,
>> I'd like to get a code review of this simple change.  It's a simple check to 
>> make sure the hostname variable is not null and throw a proper exception.
>> http://cr.openjdk.java.net/~ascarpino/8211339/webrev.00/
>> Tony

Re: sun.security.ssl.ProtocolVersion.valueOf(...) in Java8 and TLSv1.3

[Norman Maurer]

So I did some more testing and all in all it seems to work. I will do some more 
investigating still and then log the request if I can not see any negative 
side-effects.

Bye
Norman


> On 18. Sep 2018, at 18:08, Norman Maurer  wrote:
> 
> I did some testing and it seems to “just work”. I will do a bit more and then 
> come back you + filling the enhancement request.
> 
> Bye
> Norman
> 
> 
>> On 17. Sep 2018, at 18:04, Xuelei Fan  wrote:
>> 
>> Hi Norman,
>> 
>> In general, it is risk to support unknown protocol version in the key/trust 
>> manager implementation.  The trust manager implemented for TLS 1.2 and prior 
>> versions might not work with TLS 1.3 probably.  Did you make the evaluation? 
>>  Would you mind contribute a patch?
>> 
>> Please feel free to file an enhancement request, for further evaluation when 
>> there is a chance.
>> 
>> Thanks,
>> Xuelei
>> 
>> On 9/17/2018 5:28 AM, Norman Maurer wrote:
>>> Hi all,
>>> In netty we support using OpenSSL for native SSL which recently added 
>>> TLSv1.3 support as part of OpenSSL 1.1.1. In an ideal world we would be 
>>> able to use this even with Java8 which is almost true except the fact that 
>>> sun.security.ssl.ProtocolVersion.valueOf(…) will throw an 
>>> IllegalArgumentException when the string “TLSv1.3” is provided.  This is 
>>> problematic as this happens during validation in the default TrustManager 
>>> used by the OpenJDK.
>>> The stack looks something like this:
>>> java.lang.IllegalArgumentException: TLSv1.3
>>> at sun.security.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:187)
>>> at 
>>> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:258)
>>> at 
>>> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
>>> I could work around this by just wrap the SSLSession and return TLSv1.2 
>>> during validation as the same validation should be done as in the TLSv1.2 
>>> implementation but this is really just a hack.So I wonder if you would 
>>> consider to either add support for parsing TLSv1.3 to the internal enum or 
>>> just handle it more gracefully. Another thing that would work of course is 
>>> to always provide a custom X509ExtendedTrustManager but I hoped to be able 
>>> to re-use the default implementation as it already implements a lot of 
>>> verification logic.
>>> WDYT ?
>>> Norman
> 

Re: NPE during SSL handshake caused by HostnameChecker

[Norman Maurer]

Done… 

Received:

We will review your report and have assigned it an internal review ID : 9057381

I used Java8 as Java version but mentioned that it also happens on 11.

Hope it helps,
Norman


> On 24. Sep 2018, at 19:19, Xuelei Fan  wrote:
> 
> Hi Norman,
> 
> It looks like a bug to me.  Would you please file a new bug?
> 
> Thanks,
> Xuelei
> 
> On 9/22/2018 3:40 PM, Norman Maurer wrote:
>> Hi all,
>> I think I found another bug in the the SSL implementation (well really in 
>> the TrustManager related part) which leads to a NPE. I was able to reproduce 
>> this on Java8 and Java11 (ea28) but I am sure it also exists on 9 and 10.
>> While trying to write some test code for netty I did something stupid while 
>> creating the SSLEngine by passing a hostname as parameter for the server 
>> which then ended up in an NPE during handshake. I would argue we should not 
>> fail with a NPE.
>> Basically something like:
>> SSLEngine serverEngine = serverCtx.createSSLEngine("localhost", -1);
>> I think this is caused by 
>> sun.security.ssl.X509TrustManagerImpl.checkIdentity(…) missing a null check 
>> for the hostname before calling sun.security.util.HostnameChecker.match(…)
>> A full reproduce (which I extracted from my netty testcase)  can be found 
>> here (there is a README.md which explains how to run it):
>> https://github.com/normanmaurer/jdk_ssl_npe_reproducer
>> The stack I see is:
>> |Exception in thread "main" java.lang.RuntimeException: Delegated task threw 
>> Exception/Error at 
>> sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1527) at 
>> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) at 
>> sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214) at 
>> sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186) at 
>> javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469) at 
>> JDKSslReproducer.handshake(JDKSslReproducer.java:76) at 
>> JDKSslReproducer.main(JDKSslReproducer.java:51) Caused by: 
>> java.lang.NullPointerException at 
>> sun.net.util.IPAddressUtil.textToNumericFormatV4(IPAddressUtil.java:49) at 
>> sun.net.util.IPAddressUtil.isIPv4LiteralAddress(IPAddressUtil.java:241) at 
>> sun.security.util.HostnameChecker.isIpAddress(HostnameChecker.java:125) at 
>> sun.security.util.HostnameChecker.match(HostnameChecker.java:93) at 
>> sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455)
>>  at 
>> sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1068)
>>  at 
>> sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1007)
>>  at 
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601)
>>  at 
>> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) 
>> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) at 
>> sun.security.ssl.Handshaker$1.run(Handshaker.java:992) at 
>> sun.security.ssl.Handshaker$1.run(Handshaker.java:989) at 
>> java.security.AccessController.doPrivileged(Native Method) at 
>> sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) at 
>> JDKSslReproducer.runDelegatedTasks(JDKSslReproducer.java:131) at 
>> JDKSslReproducer.handshake(JDKSslReproducer.java:99) ... 1 more|
>> This only happens if a X509Trustmanager is used (not the Extended version) 
>> and when  setEndpointIdentificationAlgorithm(…) is used on the client-side.
>> Please let me know if you agree this is a bug and I am happy to open a bug 
>> for it.
>> Thanks
>> Norman

NPE during SSL handshake caused by HostnameChecker

[Norman Maurer]

Hi all,

I think I found another bug in the the SSL implementation (well really in the 
TrustManager related part) which leads to a NPE. I was able to reproduce this 
on Java8 and Java11 (ea28) but I am sure it also exists on 9 and 10. 

While trying to write some test code for netty I did something stupid while 
creating the SSLEngine by passing a hostname as parameter for the server which 
then ended up in an NPE during handshake. I would argue we should not fail with 
a NPE.

Basically something like:

SSLEngine serverEngine = serverCtx.createSSLEngine("localhost", -1);


I think this is caused by 
sun.security.ssl.X509TrustManagerImpl.checkIdentity(…) missing a null check for 
the hostname before calling sun.security.util.HostnameChecker.match(…)

A full reproduce (which I extracted from my netty testcase)  can be found here 
(there is a README.md which explains how to run it):

https://github.com/normanmaurer/jdk_ssl_npe_reproducer 


The stack I see is:

Exception in thread "main" java.lang.RuntimeException: Delegated task threw 
Exception/Error
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1527)
at 
sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
at 
sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214)
at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
at JDKSslReproducer.handshake(JDKSslReproducer.java:76)
at JDKSslReproducer.main(JDKSslReproducer.java:51)
Caused by: java.lang.NullPointerException
at 
sun.net.util.IPAddressUtil.textToNumericFormatV4(IPAddressUtil.java:49)
at 
sun.net.util.IPAddressUtil.isIPv4LiteralAddress(IPAddressUtil.java:241)
at 
sun.security.util.HostnameChecker.isIpAddress(HostnameChecker.java:125)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:93)
at 
sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455)
at 
sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1068)
at 
sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1007)
at 
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601)
at 
sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:992)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:989)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467)
at JDKSslReproducer.runDelegatedTasks(JDKSslReproducer.java:131)
at JDKSslReproducer.handshake(JDKSslReproducer.java:99)
... 1 more

This only happens if a X509Trustmanager is used (not the Extended version) and 
when  setEndpointIdentificationAlgorithm(…) is used on the client-side.

Please let me know if you agree this is a bug and I am happy to open a bug for 
it.


Thanks
Norman

Re: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Norman Maurer]

Got it... just keep in mind that this bug make it kind of unusable on the 
client-side so I think it should be a high priority to fix it rather sooner 
then later. Especially as the fix is really a one line change

Norman

> Am 20.09.2018 um 11:30 schrieb Bradford Wetmore :
> 
> Just to followup on your (Norman's) earlier question:
> 
> On 9/19/2018, Norman wrote:
> >> Is this just the
> >> initial version set or do you not plan to fix it in Java11 ?
> 
> and
> 
> On 9/19/2018 9:34 AM, Xuelei Fan wrote:
> > It is just a initial version set.
> 
> Getting this fix into JDK 12 was easy as 12 is in the early development 
> stages.  However, the GA release of JDK 11 is very close now and the bar is 
> high for any changes.
> 
> That said, we are currently looking into which JDK 11 update release would be 
> appropriate for this and a couple of other needed fixes.
> 
> Hope this helps.
> 
> Brad
> 
> 
> 
> 
>> On 9/19/2018 9:34 AM, Xuelei Fan wrote:
>> Hi Norman,
>> It is just a initial version set.
>> Thanks,
>> Xuelei
>>> On 9/19/2018 8:49 AM, Norman Maurer wrote:
>>> I see this is now tracked as 
>>> https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8210846?filter=allopenissues
>>>  :) 
>>> 
>>> Just one question, I saw it list 12 as fix version. Is this just the 
>>> initial version set or do you not plan to fix it in Java11 ? IMHO this is a 
>>> quite an important thing to fix as otherwise you may run into issues when 
>>> using SSL on the client-side as most real-world apps use OpenSSL on the 
>>> server-side.
>>> 
>>> Bye
>>> Norman
>>> 
>>> 
>>>> On 17. Sep 2018, at 10:44, Norman Maurer >>> <mailto:norman.mau...@googlemail.com>> wrote:
>>>> 
>>>> Of course not…
>>>> 
>>>> ID: 9057280
>>>> 
>>>> Thanks
>>>> Norman
>>>> 
>>>> 
>>>>> On 17. Sep 2018, at 19:35, Xuelei Fan >>>> <mailto:xuelei@oracle.com>> wrote:
>>>>> 
>>>>> Hi Norman,
>>>>> 
>>>>> Thank you so much for the reproducing code.  Would you mind file a bug 
>>>>> for this issue?
>>>>> 
>>>>> Thanks,
>>>>> Xuelei
>>>>> 
>>>>>> On 9/17/2018 3:39 AM, Norman Maurer wrote:
>>>>>> Hi all,
>>>>>> As requested I pushed a pure JDK reproducer to GitHub which you can 
>>>>>> easily use to reproduce the problem. All the details how to run it etc 
>>>>>> are in the README.md file. I also included a server to show that all 
>>>>>> works if we use the JDK on the client side and server side.
>>>>>> Also as stated before you will see that the cert will be send even if 
>>>>>> you use OpenSSL on the serverside if you replace “-Verify 1” with 
>>>>>> “-verify 1” (which is kind of the same as setWantClientAuth(true)).
>>>>>> Please don't hesitate to ping me if you need any more details or have 
>>>>>> any more questions.
>>>>>> https://github.com/normanmaurer/jdktls13bugreproducer
>>>>>> Here is the output with debugging enabled on the client side.
>>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.515 
>>>>>> CEST|SSLContextImpl.java:427|System property jdk.tls.client.cipherSuites 
>>>>>> is set to 'null'
>>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.529 
>>>>>> CEST|SSLContextImpl.java:427|System property jdk.tls.server.cipherSuites 
>>>>>> is set to 'null'
>>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.563 
>>>>>> CEST|SSLCipher.java:437|jdk.tls.keyLimits:  entry = AES/GCM/NoPadding 
>>>>>> KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472
>>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.577 
>>>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
>>>>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
>>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.577 
>>>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
>>>>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
>>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 
>>>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
>

Re: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Norman Maurer]

I can confirm that this patch fixes the issue I was seeing. After applying it 
it also passes all of the tests that we have in the SSL testsuite of netty.

So +1 from me.

Bye
Norman


> On 19. Sep 2018, at 15:13, Bradford Wetmore  
> wrote:
> 
> Looks good from a CR standpoint.  Silly typos...
> 
> Looking forward to hearing back from Norman.  I believe we are running the 
> same testbed, so I expect it will work.
> 
> Jamil, be sure to include the specific interop test information in the bug, 
> so that when SQE goes to verify, they can be sure to run it manually.
> 
> Brad
> 
> 
> On 9/19/2018 1:59 PM, Norman Maurer wrote:
>> I will test and report back later today . Thanks for the quick turnaround
>>> Am 19.09.2018 um 13:47 schrieb Jamil Nimeh :
>>> 
>>> Hello all,
>>> 
>>> This fix handles an issue in TLS client certificate authentication where 
>>> our client was failing to send a certificate after consuming the 
>>> CertificateRequest message.  Thanks to Norman Maurer for bringing this to 
>>> our attention.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210846
>>> 
>>> --Jamil
>>> 

Re: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Norman Maurer]

I will test and report back later today . Thanks for the quick turnaround

> Am 19.09.2018 um 13:47 schrieb Jamil Nimeh :
> 
> Hello all,
> 
> This fix handles an issue in TLS client certificate authentication where our 
> client was failing to send a certificate after consuming the 
> CertificateRequest message.  Thanks to Norman Maurer for bringing this to our 
> attention.
> 
> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8210846
> 
> --Jamil
> 

Re: sun.security.ssl.ProtocolVersion.valueOf(...) in Java8 and TLSv1.3

[Norman Maurer]

I did some testing and it seems to “just work”. I will do a bit more and then 
come back you + filling the enhancement request.

Bye
Norman


> On 17. Sep 2018, at 18:04, Xuelei Fan  wrote:
> 
> Hi Norman,
> 
> In general, it is risk to support unknown protocol version in the key/trust 
> manager implementation.  The trust manager implemented for TLS 1.2 and prior 
> versions might not work with TLS 1.3 probably.  Did you make the evaluation?  
> Would you mind contribute a patch?
> 
> Please feel free to file an enhancement request, for further evaluation when 
> there is a chance.
> 
> Thanks,
> Xuelei
> 
> On 9/17/2018 5:28 AM, Norman Maurer wrote:
>> Hi all,
>> In netty we support using OpenSSL for native SSL which recently added 
>> TLSv1.3 support as part of OpenSSL 1.1.1. In an ideal world we would be able 
>> to use this even with Java8 which is almost true except the fact that 
>> sun.security.ssl.ProtocolVersion.valueOf(…) will throw an 
>> IllegalArgumentException when the string “TLSv1.3” is provided.  This is 
>> problematic as this happens during validation in the default TrustManager 
>> used by the OpenJDK.
>> The stack looks something like this:
>> java.lang.IllegalArgumentException: TLSv1.3
>>  at sun.security.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:187)
>>  at 
>> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:258)
>>  at 
>> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
>> I could work around this by just wrap the SSLSession and return TLSv1.2 
>> during validation as the same validation should be done as in the TLSv1.2 
>> implementation but this is really just a hack.So I wonder if you would 
>> consider to either add support for parsing TLSv1.3 to the internal enum or 
>> just handle it more gracefully. Another thing that would work of course is 
>> to always provide a custom X509ExtendedTrustManager but I hoped to be able 
>> to re-use the default implementation as it already implements a lot of 
>> verification logic.
>> WDYT ?
>> Norman

Re: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well

[Norman Maurer]

Done..

ID: 9057278

Thanks
Norman


> On 17. Sep 2018, at 18:51, Xuelei Fan  wrote:
> 
> Hi Norman,
> 
> Please file an issue for the tracking.
> 
> Thanks,
> Xuelei
> 
> On 9/17/2018 5:57 AM, Norman Maurer wrote:
>> Should I open an issue somewhere to keep track of it or will you take care 
>> of it ?
>> Bye
>> Norman
>>> On 11. Sep 2018, at 17:01, Norman Maurer  
>>> wrote:
>>> 
>>> This sounds great.
>>> 
>>> I have no idea how many people still use X509TrustManager, sorry.
>>> 
>>> It may be a good idea to add something to the java docs to tell people to 
>>> prefer X509ExtendedTrustManager as well.
>>> 
>>> Bye
>>> Norman
>>> 
>>>> Am 11.09.2018 um 16:44 schrieb Xuelei Fan :
>>>> 
>>>> Hi Norman,
>>>> 
>>>> 
>>>> It may be doable by adding a delegation mode to public TrustManagerFactory:
>>>>  TrustManagerFactory.init(X509TrustManager proxy)
>>>> 
>>>> However, the X509ExtendedTrustManager should be recommended for now since 
>>>> its introducing in JDK 7.
>>>> 
>>>> Do you know how many users are still using the X509TrustManager 
>>>> implementation?
>>>> 
>>>> Thanks,
>>>> Xuelei
>>>> 
>>>>> On 9/11/2018 3:32 AM, Norman Maurer wrote:
>>>>> Hi all,
>>>>> Would it be possible to consider exposing 
>>>>> SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be 
>>>>> possible to reuse it when a custom SSLEngine / SSLContextSpi is provided ?
>>>>> I am asking because it provides really nice extra functionality by 
>>>>> wrapping for X509TrustManager implementation and do extra hostname checks 
>>>>> etc. At the moment we can not make use of this extra functionality in 
>>>>> netty with our custom SSLEngine implementation as there is no way to 
>>>>> access this. Which means depending on if the user use our implementation 
>>>>> or the default implementation the behaviour if quite different when using 
>>>>> a X509TrustManager in the sense that when using the default 
>>>>> implementation a lot of extra checks are done.
>>>>> As the extra checks done in AbstractTrustManagerWrapper is not really 
>>>>> depending on the underlying SSLContextSpi implementation (at least as far 
>>>>> as I was able to understand it so far) it would be nice to be able to 
>>>>> make use of it.
>>>>> Bye
>>>>> Norman

Re: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well

[Norman Maurer]

Should I open an issue somewhere to keep track of it or will you take care of 
it ?

Bye
Norman


> On 11. Sep 2018, at 17:01, Norman Maurer  wrote:
> 
> This sounds great.
> 
> I have no idea how many people still use X509TrustManager, sorry. 
> 
> It may be a good idea to add something to the java docs to tell people to 
> prefer X509ExtendedTrustManager as well.
> 
> Bye
> Norman
> 
>> Am 11.09.2018 um 16:44 schrieb Xuelei Fan :
>> 
>> Hi Norman,
>> 
>> 
>> It may be doable by adding a delegation mode to public TrustManagerFactory:
>>  TrustManagerFactory.init(X509TrustManager proxy)
>> 
>> However, the X509ExtendedTrustManager should be recommended for now since 
>> its introducing in JDK 7.
>> 
>> Do you know how many users are still using the X509TrustManager 
>> implementation?
>> 
>> Thanks,
>> Xuelei
>> 
>>> On 9/11/2018 3:32 AM, Norman Maurer wrote:
>>> Hi all,
>>> Would it be possible to consider exposing 
>>> SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible 
>>> to reuse it when a custom SSLEngine / SSLContextSpi is provided ?
>>> I am asking because it provides really nice extra functionality by wrapping 
>>> for X509TrustManager implementation and do extra hostname checks etc. At 
>>> the moment we can not make use of this extra functionality in netty with 
>>> our custom SSLEngine implementation as there is no way to access this. 
>>> Which means depending on if the user use our implementation or the default 
>>> implementation the behaviour if quite different when using a 
>>> X509TrustManager in the sense that when using the default implementation a 
>>> lot of extra checks are done.
>>> As the extra checks done in AbstractTrustManagerWrapper is not really 
>>> depending on the underlying SSLContextSpi implementation (at least as far 
>>> as I was able to understand it so far) it would be nice to be able to make 
>>> use of it.
>>> Bye
>>> Norman

sun.security.ssl.ProtocolVersion.valueOf(...) in Java8 and TLSv1.3

[Norman Maurer]

Hi all,

In netty we support using OpenSSL for native SSL which recently added TLSv1.3 
support as part of OpenSSL 1.1.1. In an ideal world we would be able to use 
this even with Java8 which is almost true except the fact that 
sun.security.ssl.ProtocolVersion.valueOf(…) will throw an 
IllegalArgumentException when the string “TLSv1.3” is provided.  This is 
problematic as this happens during validation in the default TrustManager used 
by the OpenJDK. 

The stack looks something like this:
java.lang.IllegalArgumentException: TLSv1.3
at sun.security.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:187)
at 
sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:258)
at 
sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)

I could work around this by just wrap the SSLSession and return TLSv1.2 during 
validation as the same validation should be done as in the TLSv1.2 
implementation but this is really just a hack.So I wonder if you would consider 
to either add support for parsing TLSv1.3 to the internal enum or just handle 
it more gracefully. Another thing that would work of course is to always 
provide a custom X509ExtendedTrustManager but I hoped to be able to re-use the 
default implementation as it already implements a lot of verification logic.

WDYT ?
Norman

Re: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Norman Maurer]

Will do,  but not before tomorrow (I will also share the client side code). 
That said there is nothing special about the keymanager.
Like I said before it sends the cert when using „want client with“, it just 
seems it may be too late.


Bye
Norman

> Am 15.09.2018 um 08:26 schrieb Bradford Wetmore :
> 
> It would greatly help if you can provide the client side debug output so we 
> can see what's going on locally:
> 
> -Djavax.net.debug=all or System.setProperty()
> 
> Please also let us know if you are using a custom client keymanager. It's 
> possible that it isn't properly selecting an entity to use, in which case an 
> empty message will be sent.
> 
> Brad
> 
> 
>> On 9/14/2018 11:18 PM, Norman Maurer wrote:
>> Ok will try to find time today.
>>> Am 15.09.2018 um 08:08 schrieb Xuelei Fan :
>>> 
>>> Hi Norman,
>>> 
>>> I have not had a chance to look into the details.  But sure, it helps a lot 
>>> if you can provide a java client to reproduce the issue.
>>> 
>>> Thanks,
>>> Xuelei
>>> 
>>>> On 9/14/2018 10:29 PM, Norman Maurer wrote:
>>>> Is there any more details you need ?
>>>> Just wondering. If you say so I can also provide a pure jdk client 
>>>> (without the Netty wrapper) that shows the problem when used with OpenSSL 
>>>> on the server in the next days.
>>>> Bye
>>>> Norman
>>>>> Am 13.09.2018 um 21:07 schrieb Norman Maurer 
>>>>> :
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I am currently in the process of adding TLS 1.3 support into 
>>>>> netty-tcnative[1] which uses JNI to make use of OpenSSL for it. During 
>>>>> this work I noticed that I received test-failures when mutual auth is 
>>>>> used and the JDK implementation is used on the client side. When using 
>>>>> the JDK implementation on the server and client side all works as 
>>>>> expected. Also if I use another protocol (like TLSv1.2) all works as 
>>>>> expected.
>>>>> 
>>>>> The problem I am observing is that the client seems to sent the 
>>>>> certificate “too late” and so the server (which uses openssl) will report 
>>>>> and error that the client did not provide an certificate (even when it 
>>>>> was required).
>>>>> 
>>>>> To reproduce this you can use openssl s_server like this and just create 
>>>>> your usual SSLSocket with a KeyManagerFactory configured.
>>>>> 
>>>>> ./bin/openssl s_server -tls1_3 -cert 
>>>>> ~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test.crt
>>>>>  -key 
>>>>> ~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test_unencrypted.pem
>>>>>  -4 -accept localhost:8443 -state -debug  -Verify 1
>>>>> 
>>>>> When now try to connect to it via the JDK TLS1.3 implementation I see the 
>>>>> following output:
>>>>> SSL_accept:before SSL initialization
>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5))
>>>>>  - 16 03 03 01 60`
>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160))
>>>>>  - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7   ...\.."@n}..
>>>>> 0010 - ea 34 47 a4 fa d0 bb 92-f5 62 ec f6 21 e5 ec da   .4G..b..!...
>>>>> 0020 - d6 6b 75 aa b9 34 20 b7-57 a6 83 7b c8 bc a2 0f   .ku..4 .W..{
>>>>> 0030 - 52 82 11 6f a3 1a 84 c5-4b fd e0 80 58 3c 2a bf   R..oK...X<*.
>>>>> 0040 - af 54 32 4c 7d 4f fe 00-14 c0 2c c0 2b c0 2f c0   .T2L}O,.+./.
>>>>> 0050 - 13 c0 14 00 9c 00 2f 00-35 13 01 13 02 01 00 00   ../.5...
>>>>> 0060 - ff 00 05 00 05 01 00 00-00 00 00 0a 00 20 00 1e   . ..
>>>>> 0070 - 00 17 00 18 00 19 00 09-00 0a 00 0b 00 0c 00 0d   
>>>>> 0080 - 00 0e 00 16 01 00 01 01-01 02 01 03 01 04 00 0b   
>>>>> 0090 - 00 02 01 00 00 0d 00 28-00 26 04 03 05 03 06 03   ...(.&..
>>>>> 00a0 - 08 04 08 05 08 06 08 09-08 0a 08 0b 04 01 05 01   
>>>>> 00b0 - 06 01 04 02 03 03 03 01-03 02 02 03 02 01 02 02   
>>>>> 00c0 - 00 32 00 28 00 26 04 03-05 03 06 03 08 04 08 05   .2.(.&..
>>>>> 00d0 - 08 06 0

Re: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Norman Maurer]

Ok will try to find time today.

> Am 15.09.2018 um 08:08 schrieb Xuelei Fan :
> 
> Hi Norman,
> 
> I have not had a chance to look into the details.  But sure, it helps a lot 
> if you can provide a java client to reproduce the issue.
> 
> Thanks,
> Xuelei
> 
>> On 9/14/2018 10:29 PM, Norman Maurer wrote:
>> Is there any more details you need ?
>> Just wondering. If you say so I can also provide a pure jdk client (without 
>> the Netty wrapper) that shows the problem when used with OpenSSL on the 
>> server in the next days.
>> Bye
>> Norman
>>> Am 13.09.2018 um 21:07 schrieb Norman Maurer :
>>> 
>>> Hi all,
>>> 
>>> I am currently in the process of adding TLS 1.3 support into 
>>> netty-tcnative[1] which uses JNI to make use of OpenSSL for it. During this 
>>> work I noticed that I received test-failures when mutual auth is used and 
>>> the JDK implementation is used on the client side. When using the JDK 
>>> implementation on the server and client side all works as expected. Also if 
>>> I use another protocol (like TLSv1.2) all works as expected.
>>> 
>>> The problem I am observing is that the client seems to sent the certificate 
>>> “too late” and so the server (which uses openssl) will report and error 
>>> that the client did not provide an certificate (even when it was required).
>>> 
>>> To reproduce this you can use openssl s_server like this and just create 
>>> your usual SSLSocket with a KeyManagerFactory configured.
>>> 
>>> ./bin/openssl s_server -tls1_3 -cert 
>>> ~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test.crt
>>>  -key 
>>> ~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test_unencrypted.pem
>>>  -4 -accept localhost:8443 -state -debug  -Verify 1
>>> 
>>> When now try to connect to it via the JDK TLS1.3 implementation I see the 
>>> following output:
>>> SSL_accept:before SSL initialization
>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5))
>>>  - 16 03 03 01 60`
>>> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160))
>>>  - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7   ...\.."@n}..
>>> 0010 - ea 34 47 a4 fa d0 bb 92-f5 62 ec f6 21 e5 ec da   .4G..b..!...
>>> 0020 - d6 6b 75 aa b9 34 20 b7-57 a6 83 7b c8 bc a2 0f   .ku..4 .W..{
>>> 0030 - 52 82 11 6f a3 1a 84 c5-4b fd e0 80 58 3c 2a bf   R..oK...X<*.
>>> 0040 - af 54 32 4c 7d 4f fe 00-14 c0 2c c0 2b c0 2f c0   .T2L}O,.+./.
>>> 0050 - 13 c0 14 00 9c 00 2f 00-35 13 01 13 02 01 00 00   ../.5...
>>> 0060 - ff 00 05 00 05 01 00 00-00 00 00 0a 00 20 00 1e   . ..
>>> 0070 - 00 17 00 18 00 19 00 09-00 0a 00 0b 00 0c 00 0d   
>>> 0080 - 00 0e 00 16 01 00 01 01-01 02 01 03 01 04 00 0b   
>>> 0090 - 00 02 01 00 00 0d 00 28-00 26 04 03 05 03 06 03   ...(.&..
>>> 00a0 - 08 04 08 05 08 06 08 09-08 0a 08 0b 04 01 05 01   
>>> 00b0 - 06 01 04 02 03 03 03 01-03 02 02 03 02 01 02 02   
>>> 00c0 - 00 32 00 28 00 26 04 03-05 03 06 03 08 04 08 05   .2.(.&..
>>> 00d0 - 08 06 08 09 08 0a 08 0b-04 01 05 01 06 01 04 02   
>>> 00e0 - 03 03 03 01 03 02 02 03-02 01 02 02 00 11 00 09   
>>> 00f0 - 00 07 02 00 04 00 00 00-00 00 17 00 00 00 2b 00   ..+.
>>> 0100 - 09 08 03 04 03 03 03 02-03 01 00 2d 00 02 01 01   ...-
>>> 0110 - 00 33 00 47 00 45 00 17-00 41 04 4e da b3 f2 63   .3.G.E...A.N...c
>>> 0120 - ee 6e bf e3 af 73 be c9-92 c5 ec 70 ff c7 64 b8   .n...s.p..d.
>>> 0130 - 8a 9a cc fd f9 d6 36 ef-ce e0 dc 81 01 2f 87 57   ..6../.W
>>> 0140 - 56 f0 e4 2d 8b c8 73 14-eb 5f 21 0a 5e 94 46 ba   V..-..s.._!.^.F.
>>> 0150 - de d1 33 57 4c b5 b3 66-c9 26 fb ff 01 00 01 00   ..3WL..f.&..
>>> SSL_accept:before SSL initialization
>>> SSL_accept:SSLv3/TLS read client hello
>>> SSL_accept:SSLv3/TLS write server hello
>>> SSL_accept:SSLv3/TLS write change cipher spec
>>> SSL_accept:TLSv1.3 write encrypted extensions
>>> SSL_accept:SSLv3/TLS write certificate request
>>> SSL_accept:SSLv3/TLS write certificate
>>> SSL_accept:TLSv1.3 write server certificate verify
>>> write to 0x7fe400f050c0 [0x7fe403018a00] (1430 bytes => 1430 (0x596))
>>>  - 16 03 03 00 9b 02 00 00-97 03 03 bc 7f 3b 07 

Re: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Norman Maurer]

Is there any more details you need ?

Just wondering. If you say so I can also provide a pure jdk client (without the 
Netty wrapper) that shows the problem when used with OpenSSL on the server in 
the next days.

Bye
Norman

> Am 13.09.2018 um 21:07 schrieb Norman Maurer :
> 
> Hi all,
> 
> I am currently in the process of adding TLS 1.3 support into 
> netty-tcnative[1] which uses JNI to make use of OpenSSL for it. During this 
> work I noticed that I received test-failures when mutual auth is used and the 
> JDK implementation is used on the client side. When using the JDK 
> implementation on the server and client side all works as expected. Also if I 
> use another protocol (like TLSv1.2) all works as expected.
> 
> The problem I am observing is that the client seems to sent the certificate 
> “too late” and so the server (which uses openssl) will report and error that 
> the client did not provide an certificate (even when it was required). 
> 
> To reproduce this you can use openssl s_server like this and just create your 
> usual SSLSocket with a KeyManagerFactory configured. 
> 
> ./bin/openssl s_server -tls1_3 -cert 
> ~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test.crt
>  -key 
> ~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test_unencrypted.pem
>  -4 -accept localhost:8443 -state -debug  -Verify 1
> 
> When now try to connect to it via the JDK TLS1.3 implementation I see the 
> following output:
> SSL_accept:before SSL initialization
> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5))
>  - 16 03 03 01 60`
> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160))
>  - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7   ...\.."@n}..
> 0010 - ea 34 47 a4 fa d0 bb 92-f5 62 ec f6 21 e5 ec da   .4G..b..!...
> 0020 - d6 6b 75 aa b9 34 20 b7-57 a6 83 7b c8 bc a2 0f   .ku..4 .W..{
> 0030 - 52 82 11 6f a3 1a 84 c5-4b fd e0 80 58 3c 2a bf   R..oK...X<*.
> 0040 - af 54 32 4c 7d 4f fe 00-14 c0 2c c0 2b c0 2f c0   .T2L}O,.+./.
> 0050 - 13 c0 14 00 9c 00 2f 00-35 13 01 13 02 01 00 00   ../.5...
> 0060 - ff 00 05 00 05 01 00 00-00 00 00 0a 00 20 00 1e   . ..
> 0070 - 00 17 00 18 00 19 00 09-00 0a 00 0b 00 0c 00 0d   
> 0080 - 00 0e 00 16 01 00 01 01-01 02 01 03 01 04 00 0b   
> 0090 - 00 02 01 00 00 0d 00 28-00 26 04 03 05 03 06 03   ...(.&..
> 00a0 - 08 04 08 05 08 06 08 09-08 0a 08 0b 04 01 05 01   
> 00b0 - 06 01 04 02 03 03 03 01-03 02 02 03 02 01 02 02   
> 00c0 - 00 32 00 28 00 26 04 03-05 03 06 03 08 04 08 05   .2.(.&..
> 00d0 - 08 06 08 09 08 0a 08 0b-04 01 05 01 06 01 04 02   
> 00e0 - 03 03 03 01 03 02 02 03-02 01 02 02 00 11 00 09   
> 00f0 - 00 07 02 00 04 00 00 00-00 00 17 00 00 00 2b 00   ..+.
> 0100 - 09 08 03 04 03 03 03 02-03 01 00 2d 00 02 01 01   ...-
> 0110 - 00 33 00 47 00 45 00 17-00 41 04 4e da b3 f2 63   .3.G.E...A.N...c
> 0120 - ee 6e bf e3 af 73 be c9-92 c5 ec 70 ff c7 64 b8   .n...s.p..d.
> 0130 - 8a 9a cc fd f9 d6 36 ef-ce e0 dc 81 01 2f 87 57   ..6../.W
> 0140 - 56 f0 e4 2d 8b c8 73 14-eb 5f 21 0a 5e 94 46 ba   V..-..s.._!.^.F.
> 0150 - de d1 33 57 4c b5 b3 66-c9 26 fb ff 01 00 01 00   ..3WL..f.&..
> SSL_accept:before SSL initialization
> SSL_accept:SSLv3/TLS read client hello
> SSL_accept:SSLv3/TLS write server hello
> SSL_accept:SSLv3/TLS write change cipher spec
> SSL_accept:TLSv1.3 write encrypted extensions
> SSL_accept:SSLv3/TLS write certificate request
> SSL_accept:SSLv3/TLS write certificate
> SSL_accept:TLSv1.3 write server certificate verify
> write to 0x7fe400f050c0 [0x7fe403018a00] (1430 bytes => 1430 (0x596))
>  - 16 03 03 00 9b 02 00 00-97 03 03 bc 7f 3b 07 ad   .;..
> 0010 - fb 21 9c 6f 7c 4a 9d 84-9a 82 6e 9c 1a b4 e3 5d   .!.o|Jn]
> 0020 - a8 d3 9d 52 a7 e1 93 c3-cc 8c 82 20 b7 57 a6 83   ...R... .W..
> 0030 - 7b c8 bc a2 0f 52 82 11-6f a3 1a 84 c5 4b fd e0   {R..oK..
> 0040 - 80 58 3c 2a bf af 54 32-4c 7d 4f fe 13 01 00 00   .X<*..T2L}O.
> 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04   O.+.3.E...A.
> 0060 - 7d 81 11 ab ff a6 60 e7-5f 23 82 ed 22 35 76 24   }.`._#.."5v$
> 0070 - b0 47 09 25 0c 79 b9 07-5b 3e 28 b7 3c d8 d3 ce   .G.%.y..[>(.<...
> 0080 - 6b 89 c6 01 21 28 c9 97-ae 50 a5 e7 43 35 ae c7   k...!(...P..C5..
> 0090 - 73 10 60 62 57 25 9b c9-f1 93 28 70 03 44 e1 a0   s.`bW%(p.D..
> 00a0 - 14 03 03 00 01 01 17 03-03 00 27 0f 8b fb 2d 33   ..'...-3
> 00b0 - 72 c6 a8 28 0b 7d e1 c3-b7 d0 f3 d9 18 5b ca 

TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth

[Norman Maurer]

Hi all,

I am currently in the process of adding TLS 1.3 support into netty-tcnative[1] 
which uses JNI to make use of OpenSSL for it. During this work I noticed that I 
received test-failures when mutual auth is used and the JDK implementation is 
used on the client side. When using the JDK implementation on the server and 
client side all works as expected. Also if I use another protocol (like 
TLSv1.2) all works as expected.

The problem I am observing is that the client seems to sent the certificate 
“too late” and so the server (which uses openssl) will report and error that 
the client did not provide an certificate (even when it was required). 

To reproduce this you can use openssl s_server like this and just create your 
usual SSLSocket with a KeyManagerFactory configured. 

./bin/openssl s_server -tls1_3 -cert 
~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test.crt
 -key 
~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test_unencrypted.pem
 -4 -accept localhost:8443 -state -debug  -Verify 1

When now try to connect to it via the JDK TLS1.3 implementation I see the 
following output:
SSL_accept:before SSL initialization
read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5))
 - 16 03 03 01 60`
read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160))
 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7   ...\.."@n}..
0010 - ea 34 47 a4 fa d0 bb 92-f5 62 ec f6 21 e5 ec da   .4G..b..!...
0020 - d6 6b 75 aa b9 34 20 b7-57 a6 83 7b c8 bc a2 0f   .ku..4 .W..{
0030 - 52 82 11 6f a3 1a 84 c5-4b fd e0 80 58 3c 2a bf   R..oK...X<*.
0040 - af 54 32 4c 7d 4f fe 00-14 c0 2c c0 2b c0 2f c0   .T2L}O,.+./.
0050 - 13 c0 14 00 9c 00 2f 00-35 13 01 13 02 01 00 00   ../.5...
0060 - ff 00 05 00 05 01 00 00-00 00 00 0a 00 20 00 1e   . ..
0070 - 00 17 00 18 00 19 00 09-00 0a 00 0b 00 0c 00 0d   
0080 - 00 0e 00 16 01 00 01 01-01 02 01 03 01 04 00 0b   
0090 - 00 02 01 00 00 0d 00 28-00 26 04 03 05 03 06 03   ...(.&..
00a0 - 08 04 08 05 08 06 08 09-08 0a 08 0b 04 01 05 01   
00b0 - 06 01 04 02 03 03 03 01-03 02 02 03 02 01 02 02   
00c0 - 00 32 00 28 00 26 04 03-05 03 06 03 08 04 08 05   .2.(.&..
00d0 - 08 06 08 09 08 0a 08 0b-04 01 05 01 06 01 04 02   
00e0 - 03 03 03 01 03 02 02 03-02 01 02 02 00 11 00 09   
00f0 - 00 07 02 00 04 00 00 00-00 00 17 00 00 00 2b 00   ..+.
0100 - 09 08 03 04 03 03 03 02-03 01 00 2d 00 02 01 01   ...-
0110 - 00 33 00 47 00 45 00 17-00 41 04 4e da b3 f2 63   .3.G.E...A.N...c
0120 - ee 6e bf e3 af 73 be c9-92 c5 ec 70 ff c7 64 b8   .n...s.p..d.
0130 - 8a 9a cc fd f9 d6 36 ef-ce e0 dc 81 01 2f 87 57   ..6../.W
0140 - 56 f0 e4 2d 8b c8 73 14-eb 5f 21 0a 5e 94 46 ba   V..-..s.._!.^.F.
0150 - de d1 33 57 4c b5 b3 66-c9 26 fb ff 01 00 01 00   ..3WL..f.&..
SSL_accept:before SSL initialization
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write change cipher spec
SSL_accept:TLSv1.3 write encrypted extensions
SSL_accept:SSLv3/TLS write certificate request
SSL_accept:SSLv3/TLS write certificate
SSL_accept:TLSv1.3 write server certificate verify
write to 0x7fe400f050c0 [0x7fe403018a00] (1430 bytes => 1430 (0x596))
 - 16 03 03 00 9b 02 00 00-97 03 03 bc 7f 3b 07 ad   .;..
0010 - fb 21 9c 6f 7c 4a 9d 84-9a 82 6e 9c 1a b4 e3 5d   .!.o|Jn]
0020 - a8 d3 9d 52 a7 e1 93 c3-cc 8c 82 20 b7 57 a6 83   ...R... .W..
0030 - 7b c8 bc a2 0f 52 82 11-6f a3 1a 84 c5 4b fd e0   {R..oK..
0040 - 80 58 3c 2a bf af 54 32-4c 7d 4f fe 13 01 00 00   .X<*..T2L}O.
0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04   O.+.3.E...A.
0060 - 7d 81 11 ab ff a6 60 e7-5f 23 82 ed 22 35 76 24   }.`._#.."5v$
0070 - b0 47 09 25 0c 79 b9 07-5b 3e 28 b7 3c d8 d3 ce   .G.%.y..[>(.<...
0080 - 6b 89 c6 01 21 28 c9 97-ae 50 a5 e7 43 35 ae c7   k...!(...P..C5..
0090 - 73 10 60 62 57 25 9b c9-f1 93 28 70 03 44 e1 a0   s.`bW%(p.D..
00a0 - 14 03 03 00 01 01 17 03-03 00 27 0f 8b fb 2d 33   ..'...-3
00b0 - 72 c6 a8 28 0b 7d e1 c3-b7 d0 f3 d9 18 5b ca e0   r..(.}...[..
00c0 - 56 09 74 48 ba 28 16 1c-15 11 d9 fa 6e b3 bc b9   V.tH.(..n...
00d0 - 4d 54 17 03 03 00 42 35-53 5b 9a 8e 09 df 86 c4   MTB5S[..
00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65   .(.m...8.wrs%&.e
00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96   XP..
0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9   .;<..AX...:(..a.
0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5   .h...f.[. ..
0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb   .RD...c=
0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6   .*O[J.wx.u. 
0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee   ...VV._.e.~n=.f.
01

Re: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well

[Norman Maurer]

This sounds great.

I have no idea how many people still use X509TrustManager, sorry. 

It may be a good idea to add something to the java docs to tell people to 
prefer X509ExtendedTrustManager as well.

Bye
Norman

> Am 11.09.2018 um 16:44 schrieb Xuelei Fan :
> 
> Hi Norman,
> 
> 
> It may be doable by adding a delegation mode to public TrustManagerFactory:
>   TrustManagerFactory.init(X509TrustManager proxy)
> 
> However, the X509ExtendedTrustManager should be recommended for now since its 
> introducing in JDK 7.
> 
> Do you know how many users are still using the X509TrustManager 
> implementation?
> 
> Thanks,
> Xuelei
> 
>> On 9/11/2018 3:32 AM, Norman Maurer wrote:
>> Hi all,
>> Would it be possible to consider exposing 
>> SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible 
>> to reuse it when a custom SSLEngine / SSLContextSpi is provided ?
>> I am asking because it provides really nice extra functionality by wrapping 
>> for X509TrustManager implementation and do extra hostname checks etc. At the 
>> moment we can not make use of this extra functionality in netty with our 
>> custom SSLEngine implementation as there is no way to access this. Which 
>> means depending on if the user use our implementation or the default 
>> implementation the behaviour if quite different when using a 
>> X509TrustManager in the sense that when using the default implementation a 
>> lot of extra checks are done.
>> As the extra checks done in AbstractTrustManagerWrapper is not really 
>> depending on the underlying SSLContextSpi implementation (at least as far as 
>> I was able to understand it so far) it would be nice to be able to make use 
>> of it.
>> Bye
>> Norman

Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well

[Norman Maurer]

Hi all,

Would it be possible to consider exposing 
SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible to 
reuse it when a custom SSLEngine / SSLContextSpi is provided ?

I am asking because it provides really nice extra functionality by wrapping for 
X509TrustManager implementation and do extra hostname checks etc. At the moment 
we can not make use of this extra functionality in netty with our custom 
SSLEngine implementation as there is no way to access this. Which means 
depending on if the user use our implementation or the default implementation 
the behaviour if quite different when using a X509TrustManager in the sense 
that when using the default implementation a lot of extra checks are done. 

As the extra checks done in AbstractTrustManagerWrapper is not really depending 
on the underlying SSLContextSpi implementation (at least as far as I was able 
to understand it so far) it would be nice to be able to make use of it.

Bye
Norman

Re: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029

[Norman Maurer]

I there any idea when the patch will be merged and a release will be cut so we 
can enable testing with JDK11 again for netty ?


> On 31. Jul 2018, at 07:19, Norman Maurer  wrote:
> 
> After digging more this morning I noticed the test code did made some wrong 
> assumptions which just worked out of luck before. After fixing the test 
> everything passes now.
> 
> So +1 from me on the patch :)
> 
> Also sorry for the false-alarm.
> 
> Niorman
> 
> 
>> On 30. Jul 2018, at 22:23, Xuelei Fan  wrote:
>> 
>> Would you mind send me the debug log (-Djavax.net.debug=all) and the 
>> exception stacks?  The "renegotiation" in TLS 1.3 is different from TLS 1.2 
>> and prior specifications.  It would be helpful to me to find the cause of 
>> the test failure.
>> 
>> Thanks,
>> Xuelei
>> 
>> On 7/30/2018 1:11 PM, Norman Maurer wrote:
>>> Sorry but I just noticed we still have a another integration test failing 
>>> which tests that client SSL renegotiation is failing. This seems to be not 
>>> the case anymore with java11 + your patch (it was in ea20 tho).
>>> https://github.com/netty/netty/blob/netty-4.1.28.Final/testsuite/src/main/java/io/netty/testsuite/transport/socket/SocketSslClientRenegotiateTest.java
>>> Let me know if I need to dig more into it.
>>> Bye
>>> Norman
>>>> On 30. Jul 2018, at 21:54, Norman Maurer >>> <mailto:norman.mau...@googlemail.com>> wrote:
>>>> 
>>>> Hey Xuelei,
>>>> 
>>>> I just re-ran our testsuite with your patch and everything pass except two 
>>>> tests. After digging a bit I found that we needed to add explicit calls to 
>>>> `SSLEngine.setUSeClientMode(false)` now in these test where we did not 
>>>> need to do this before.
>>>> 
>>>> The tests in question are:
>>>> 
>>>> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L400
>>>> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L418
>>>> 
>>>> Here we use SslContext.getDefault().createSSLEngine() and did not set the 
>>>> mode explicitly before. With the following patch to netty all works when 
>>>> using your patch:
>>>> 
>>>> diff --git 
>>>> a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java 
>>>> b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java
>>>> index e982b6a63..40d6e7b59 100644
>>>> --- a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java
>>>> +++ b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java
>>>> @@ -398,7 +398,9 @@ public class SslHandlerTest {
>>>> @Test
>>>> public void testCloseFutureNotified() throws Exception {
>>>> -SslHandler handler = new 
>>>> SslHandler(SSLContext.getDefault().createSSLEngine());
>>>> +SSLEngine engine = SSLContext.getDefault().createSSLEngine();
>>>> +engine.setUseClientMode(false);
>>>> +SslHandler handler = new SslHandler(engine);
>>>> EmbeddedChannel ch = new EmbeddedChannel(handler);
>>>> ch.close();
>>>> @@ -417,6 +419,7 @@ public class SslHandlerTest {
>>>> @Test(timeout = 5000)
>>>> public void testEventsFired() throws Exception {
>>>> SSLEngine engine = SSLContext.getDefault().createSSLEngine();
>>>> +engine.setUseClientMode(false);
>>>> final BlockingQueue events = new 
>>>> LinkedBlockingQueue();
>>>> EmbeddedChannel channel = new EmbeddedChannel(new 
>>>> SslHandler(engine), new ChannelInboundHandlerAdapter() {
>>>> @Override
>>>> 
>>>> 
>>>> The exception we see without the patch is:
>>>> 
>>>> java.lang.IllegalStateException: Client/Server mode has not yet been set.
>>>> at 
>>>> java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:98)
>>>> at io.netty.handler.ssl.SslHandler.handshake(SslHandler.java:1731)
>>>> at 
>>>> io.netty.handler.ssl.SslHandler.startHandshakeProcessing(SslHandler.java:1644)
>>>> at io.netty.handler.ssl.SslHandler.handlerAdded(SslHandler.java:1634)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637)
>>>&

Re: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029

[Norman Maurer]

After digging more this morning I noticed the test code did made some wrong 
assumptions which just worked out of luck before. After fixing the test 
everything passes now.

So +1 from me on the patch :)

Also sorry for the false-alarm.

Niorman


> On 30. Jul 2018, at 22:23, Xuelei Fan  wrote:
> 
> Would you mind send me the debug log (-Djavax.net.debug=all) and the 
> exception stacks?  The "renegotiation" in TLS 1.3 is different from TLS 1.2 
> and prior specifications.  It would be helpful to me to find the cause of the 
> test failure.
> 
> Thanks,
> Xuelei
> 
> On 7/30/2018 1:11 PM, Norman Maurer wrote:
>> Sorry but I just noticed we still have a another integration test failing 
>> which tests that client SSL renegotiation is failing. This seems to be not 
>> the case anymore with java11 + your patch (it was in ea20 tho).
>> https://github.com/netty/netty/blob/netty-4.1.28.Final/testsuite/src/main/java/io/netty/testsuite/transport/socket/SocketSslClientRenegotiateTest.java
>> Let me know if I need to dig more into it.
>> Bye
>> Norman
>>> On 30. Jul 2018, at 21:54, Norman Maurer >> <mailto:norman.mau...@googlemail.com>> wrote:
>>> 
>>> Hey Xuelei,
>>> 
>>> I just re-ran our testsuite with your patch and everything pass except two 
>>> tests. After digging a bit I found that we needed to add explicit calls to 
>>> `SSLEngine.setUSeClientMode(false)` now in these test where we did not need 
>>> to do this before.
>>> 
>>> The tests in question are:
>>> 
>>> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L400
>>> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L418
>>> 
>>> Here we use SslContext.getDefault().createSSLEngine() and did not set the 
>>> mode explicitly before. With the following patch to netty all works when 
>>> using your patch:
>>> 
>>> diff --git a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java 
>>> b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java
>>> index e982b6a63..40d6e7b59 100644
>>> --- a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java
>>> +++ b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java
>>> @@ -398,7 +398,9 @@ public class SslHandlerTest {
>>>  @Test
>>>  public void testCloseFutureNotified() throws Exception {
>>> -SslHandler handler = new 
>>> SslHandler(SSLContext.getDefault().createSSLEngine());
>>> +SSLEngine engine = SSLContext.getDefault().createSSLEngine();
>>> +engine.setUseClientMode(false);
>>> +SslHandler handler = new SslHandler(engine);
>>>  EmbeddedChannel ch = new EmbeddedChannel(handler);
>>>  ch.close();
>>> @@ -417,6 +419,7 @@ public class SslHandlerTest {
>>>  @Test(timeout = 5000)
>>>  public void testEventsFired() throws Exception {
>>>  SSLEngine engine = SSLContext.getDefault().createSSLEngine();
>>> +engine.setUseClientMode(false);
>>>  final BlockingQueue events = new 
>>> LinkedBlockingQueue();
>>>  EmbeddedChannel channel = new EmbeddedChannel(new 
>>> SslHandler(engine), new ChannelInboundHandlerAdapter() {
>>>  @Override
>>> 
>>> 
>>> The exception we see without the patch is:
>>> 
>>> java.lang.IllegalStateException: Client/Server mode has not yet been set.
>>> at 
>>> java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:98)
>>> at io.netty.handler.ssl.SslHandler.handshake(SslHandler.java:1731)
>>> at 
>>> io.netty.handler.ssl.SslHandler.startHandshakeProcessing(SslHandler.java:1644)
>>> at io.netty.handler.ssl.SslHandler.handlerAdded(SslHandler.java:1634)
>>> at 
>>> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637)
>>> at 
>>> io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:235)
>>> at 
>>> io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:409)
>>> at 
>>> io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:396)
>>> at 
>>> io.netty.channel.embedded.EmbeddedChannel$2.initChannel(EmbeddedChannel.java:203)
>>> at 
>>> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:115)
>>&g

Re: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029

[Norman Maurer]

Sorry but I just noticed we still have a another integration test failing which 
tests that client SSL renegotiation is failing. This seems to be not the case 
anymore with java11 + your patch (it was in ea20 tho).

https://github.com/netty/netty/blob/netty-4.1.28.Final/testsuite/src/main/java/io/netty/testsuite/transport/socket/SocketSslClientRenegotiateTest.java
 
<https://github.com/netty/netty/blob/netty-4.1.28.Final/testsuite/src/main/java/io/netty/testsuite/transport/socket/SocketSslClientRenegotiateTest.java>


Let me know if I need to dig more into it.

Bye
Norman


> On 30. Jul 2018, at 21:54, Norman Maurer  wrote:
> 
> Hey Xuelei,
> 
> I just re-ran our testsuite with your patch and everything pass except two 
> tests. After digging a bit I found that we needed to add explicit calls to 
> `SSLEngine.setUSeClientMode(false)` now in these test where we did not need 
> to do this before.
> 
> The tests in question are:
> 
> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L400
>  
> <https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L400>
> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L418
>  
> <https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L418>
> 
> Here we use SslContext.getDefault().createSSLEngine() and did not set the 
> mode explicitly before. With the following patch to netty all works when 
> using your patch:
> 
> diff --git a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java 
> b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java
> index e982b6a63..40d6e7b59 100644
> --- a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java
> +++ b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java
> @@ -398,7 +398,9 @@ public class SslHandlerTest {
>  
>  @Test
>  public void testCloseFutureNotified() throws Exception {
> -SslHandler handler = new 
> SslHandler(SSLContext.getDefault().createSSLEngine());
> +SSLEngine engine = SSLContext.getDefault().createSSLEngine();
> +engine.setUseClientMode(false);
> +SslHandler handler = new SslHandler(engine);
>  EmbeddedChannel ch = new EmbeddedChannel(handler);
>  
>  ch.close();
> @@ -417,6 +419,7 @@ public class SslHandlerTest {
>  @Test(timeout = 5000)
>  public void testEventsFired() throws Exception {
>  SSLEngine engine = SSLContext.getDefault().createSSLEngine();
> +engine.setUseClientMode(false);
>  final BlockingQueue events = new 
> LinkedBlockingQueue();
>  EmbeddedChannel channel = new EmbeddedChannel(new 
> SslHandler(engine), new ChannelInboundHandlerAdapter() {
>  @Override
> 
> 
> The exception we see without the patch is:
> 
> java.lang.IllegalStateException: Client/Server mode has not yet been set.
>   at 
> java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:98)
>   at io.netty.handler.ssl.SslHandler.handshake(SslHandler.java:1731)
>   at 
> io.netty.handler.ssl.SslHandler.startHandshakeProcessing(SslHandler.java:1644)
>   at io.netty.handler.ssl.SslHandler.handlerAdded(SslHandler.java:1634)
>   at 
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637)
>   at 
> io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:235)
>   at 
> io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:409)
>   at 
> io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:396)
>   at 
> io.netty.channel.embedded.EmbeddedChannel$2.initChannel(EmbeddedChannel.java:203)
>   at 
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:115)
>   at 
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:107)
>   at 
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637)
>   at 
> io.netty.channel.DefaultChannelPipeline.access$000(DefaultChannelPipeline.java:46)
>   at 
> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1487)
>   at 
> io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1161)
>   at 
> io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:686)
>   at 
> io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:

Re: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029

[Norman Maurer]

rImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at 
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at 
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)


So I have no problem to patch our test-case but I wondered if this may break 
others in other cases and so is a regression. 

Let me know what you think.
Norman

> On 30. Jul 2018, at 20:06, Norman Maurer  wrote:
> 
> Will do and report back as soon as possible.
> 
> Thanks
> Norman
> 
> 
>> On 30. Jul 2018, at 19:57, Xuelei Fan  wrote:
>> 
>> Hi Norman,
>> 
>> Would you mind look at the code I posted in the following thread:
>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html
>> 
>> I appreciate if you could have a test by the end of this week.
>> 
>> Note that with this update, a complete TLS connection should close both 
>> inbound and outbound explicitly.  However, existing applications may not did 
>> this way.  If the source code update is not available, please consider to 
>> use the "jdk.tls.acknowledgeCloseNotify" as a workaround.
>> 
>> Thanks,
>> Xuelei
>> 
>> On 7/25/2018 11:22 PM, Norman Maurer wrote:
>>> Just FYI… I tested this patch via the netty ssl tests and we no longer see 
>>> the class-cast-exception problems I reported before dso I think this solves 
>>> the issue.
>>> That said we still encounter a few test-failures for tests that test 
>>> behaviour of closing outbound of the SSLEngine but I think these are more 
>>> related to 
>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html 
>>> and 
>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html .
>>> Bye
>>> Norman
>>>> On 25. Jul 2018, at 20:30, Xuelei Fan >>> <mailto:xuelei@oracle.com>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Please review the update for JDK-8208166:
>>>> http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ 
>>>> <http://cr.openjdk.java.net/%7Exuelei/8208166/webrev.00/>
>>>> https://bugs.openjdk.java.net/browse/JDK-8208166
>>>> 
>>>> Thanks,
>>>> Xuelei
> 

Re: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029

[Norman Maurer]

Will do and report back as soon as possible.

Thanks
Norman


> On 30. Jul 2018, at 19:57, Xuelei Fan  wrote:
> 
> Hi Norman,
> 
> Would you mind look at the code I posted in the following thread:
> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html
> 
> I appreciate if you could have a test by the end of this week.
> 
> Note that with this update, a complete TLS connection should close both 
> inbound and outbound explicitly.  However, existing applications may not did 
> this way.  If the source code update is not available, please consider to use 
> the "jdk.tls.acknowledgeCloseNotify" as a workaround.
> 
> Thanks,
> Xuelei
> 
> On 7/25/2018 11:22 PM, Norman Maurer wrote:
>> Just FYI… I tested this patch via the netty ssl tests and we no longer see 
>> the class-cast-exception problems I reported before dso I think this solves 
>> the issue.
>> That said we still encounter a few test-failures for tests that test 
>> behaviour of closing outbound of the SSLEngine but I think these are more 
>> related to 
>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html 
>> and 
>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html .
>> Bye
>> Norman
>>> On 25. Jul 2018, at 20:30, Xuelei Fan >> <mailto:xuelei@oracle.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> Please review the update for JDK-8208166:
>>> http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Exuelei/8208166/webrev.00/>
>>> https://bugs.openjdk.java.net/browse/JDK-8208166
>>> 
>>> Thanks,
>>> Xuelei

Re: Code Review Request, JDK-8208166, Still unable to use custom SSLEngine with default TrustManagerFactory after JDK-8207029

[Norman Maurer]

Just FYI… I tested this patch via the netty ssl tests and we no longer see the 
class-cast-exception problems I reported before dso I think this solves the 
issue.


That said we still encounter a few test-failures for tests that test behaviour 
of closing outbound of the SSLEngine but I think these are more related to 
http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html 
 and 
http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html 
 .

Bye
Norman



> On 25. Jul 2018, at 20:30, Xuelei Fan  wrote:
> 
> Hi,
> 
> Please review the update for JDK-8208166:
>   http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/
>   https://bugs.openjdk.java.net/browse/JDK-8208166
> 
> Thanks,
> Xuelei

Re: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later)

[Norman Maurer]

thanks… used the wrong mailing list again :(



> On 10. Jul 2018, at 17:57, Alan Bateman  wrote:
> 
> Forwarding to security-dev.
> 
> On 10/07/2018 17:47, Norman Maurer wrote:
>> Hi all,
>> 
>> I just tried to run netty[1] testsuite with the latest jdk11 EA release (21) 
>> and saw some class-cast-exception with our custom SSLEngine implementation
>> 
>> 
>> Caused by: java.lang.ClassCastException: class 
>> io.netty.handler.ssl.OpenSslEngine cannot be cast to class 
>> sun.security.ssl.SSLEngineImpl (io.netty.handler.ssl.OpenSslEngine is in 
>> unnamed module of loader 'app'; sun.security.ssl.SSLEngineImpl is in module 
>> java.base of loader 'bootstrap')
>>  at 
>> java.base/sun.security.ssl.SSLAlgorithmConstraints.(SSLAlgorithmConstraints.java:93)
>>  at 
>> java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:270)
>>  at 
>> java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:141)
>>  at 
>> io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:237)
>>  at 
>> io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(ReferenceCountedOpenSslContext.java:621)
>>  ... 27 more
>> 
>> 
>> This change seems to be related to:
>> http://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea 
>> <http://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea>
>> 
>> I think you miss an instanceof check here in SSLAlgorithmConstraints before 
>> try to cast to SSLEngineImpl, as otherwise it will be impossible to use 
>> custom implementations of SSLEngine (which we have in netty) with the 
>> default TrustManagerFactory.
>> 
>> Does this sound correct ? Should I open a bug-report ?
>> 
>> Bye
>> Norman
>> 
>> 
>> 
> 

Re: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later)

[Norman Maurer]

Hey Pallavi,

Thanks :)

I just noticed you will also need to do the instanceof before you cast to 
SocketImpl in this class. Unfortunately I can not add a comment this issue 
directly (it seems), so hopefully mention it here is good enough.

Bye
Norman



> On 11. Jul 2018, at 08:54, Pallavi Sonal  wrote:
> 
> Hi Norman ,
> Please refer https://bugs.openjdk.java.net/browse/JDK-8207029 to view your 
> report, it has been moved to JDK.
> 
> Thanks,
> Pallavi Sonal
> 
> Message: 5
> Date: Wed, 11 Jul 2018 08:21:44 +0200
> From: Norman Maurer 
> To: Xuelei Fan 
> Cc: OpenJDK Dev list 
> Subject: Re: Unable to use custom SSLEngine with default
>   TrustManagerFactory after updating to ea20 (and later)
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
> 
> Submitted it via https://bugreport.java.com <https://bugreport.java.com/>.
> 
> Please let me know once it ?transferred? to https://bugs.openjdk.java.net 
> <https://bugs.openjdk.java.net/>
> 
> 
> Bye
> Norman
> 
> 
> 
>> On 10. Jul 2018, at 20:26, Norman Maurer  
>> wrote:
>> 
>> Will do tomorrow latest.
>> 
>> Thanks for the quick reply.
>> 
>> Bye
>> Norman
>> 
>>> Am 10.07.2018 um 18:53 schrieb Xuelei Fan :
>>> 
>>> Hi Norman,
>>> 
>>> It's an interesting user case of the TrustManagerFactory.  Please file a 
>>> bug.
>>> 
>>> Thanks,
>>> Xuelei
>>> 
>>>> On 7/10/2018 9:57 AM, Alan Bateman wrote:
>>>> Forwarding to security-dev.
>>>>> On 10/07/2018 17:47, Norman Maurer wrote:
>>>>> Hi all,
>>>>> 
>>>>> I just tried to run netty[1] testsuite with the latest jdk11 EA 
>>>>> release (21) and saw some class-cast-exception with our custom 
>>>>> SSLEngine implementation
>>>>> 
>>>>> 
>>>>> Caused by: java.lang.ClassCastException: class 
>>>>> io.netty.handler.ssl.OpenSslEngine cannot be cast to class 
>>>>> sun.security.ssl.SSLEngineImpl (io.netty.handler.ssl.OpenSslEngine 
>>>>> is in unnamed module of loader 'app'; 
>>>>> sun.security.ssl.SSLEngineImpl is in module java.base of loader 
>>>>> 'bootstrap') at 
>>>>> java.base/sun.security.ssl.SSLAlgorithmConstraints.(SSLAlgori
>>>>> thmConstraints.java:93) at 
>>>>> java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509Tr
>>>>> ustManagerImpl.java:270) at 
>>>>> java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(
>>>>> X509TrustManagerImpl.java:141) at 
>>>>> io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedT
>>>>> rustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientConte
>>>>> xt.java:237) at 
>>>>> io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertifi
>>>>> cateVerifier.verify(ReferenceCountedOpenSslContext.java:621)
>>>>> ... 27 more
>>>>> 
>>>>> 
>>>>> This change seems to be related to:
>>>>> http://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea
>>>>> 
>>>>> I think you miss an instanceof check here in SSLAlgorithmConstraints 
>>>>> before try to cast to SSLEngineImpl, as otherwise it will be impossible 
>>>>> to use custom implementations of SSLEngine (which we have in netty) with 
>>>>> the default TrustManagerFactory.
>>>>> 
>>>>> Does this sound correct ? Should I open a bug-report ?
>>>>> 
>>>>> Bye
>>>>> Norman
>>>>> 
>>>>> 
>>>>> 
> 
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20180711/c207ae06/attachment.html>
> 
> End of security-dev Digest, Vol 133, Issue 12
> *

Re: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later)

[Norman Maurer]

Submitted it via https://bugreport.java.com <https://bugreport.java.com/>.

Please let me know once it “transferred” to https://bugs.openjdk.java.net 
<https://bugs.openjdk.java.net/>


Bye
Norman



> On 10. Jul 2018, at 20:26, Norman Maurer  wrote:
> 
> Will do tomorrow latest.
> 
> Thanks for the quick reply.
> 
> Bye
> Norman 
> 
>> Am 10.07.2018 um 18:53 schrieb Xuelei Fan :
>> 
>> Hi Norman,
>> 
>> It's an interesting user case of the TrustManagerFactory.  Please file a bug.
>> 
>> Thanks,
>> Xuelei
>> 
>>> On 7/10/2018 9:57 AM, Alan Bateman wrote:
>>> Forwarding to security-dev.
>>>> On 10/07/2018 17:47, Norman Maurer wrote:
>>>> Hi all,
>>>> 
>>>> I just tried to run netty[1] testsuite with the latest jdk11 EA release 
>>>> (21) and saw some class-cast-exception with our custom SSLEngine 
>>>> implementation
>>>> 
>>>> 
>>>> Caused by: java.lang.ClassCastException: class 
>>>> io.netty.handler.ssl.OpenSslEngine cannot be cast to class 
>>>> sun.security.ssl.SSLEngineImpl (io.netty.handler.ssl.OpenSslEngine is in 
>>>> unnamed module of loader 'app'; sun.security.ssl.SSLEngineImpl is in 
>>>> module java.base of loader 'bootstrap')
>>>> at 
>>>> java.base/sun.security.ssl.SSLAlgorithmConstraints.(SSLAlgorithmConstraints.java:93)
>>>> at 
>>>> java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:270)
>>>> at 
>>>> java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:141)
>>>> at 
>>>> io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:237)
>>>> at 
>>>> io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(ReferenceCountedOpenSslContext.java:621)
>>>> ... 27 more
>>>> 
>>>> 
>>>> This change seems to be related to:
>>>> http://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea
>>>> 
>>>> I think you miss an instanceof check here in SSLAlgorithmConstraints 
>>>> before try to cast to SSLEngineImpl, as otherwise it will be impossible to 
>>>> use custom implementations of SSLEngine (which we have in netty) with the 
>>>> default TrustManagerFactory.
>>>> 
>>>> Does this sound correct ? Should I open a bug-report ?
>>>> 
>>>> Bye
>>>> Norman
>>>> 
>>>> 
>>>> 

Re: Unable to use custom SSLEngine with default TrustManagerFactory after updating to ea20 (and later)

[Norman Maurer]

Will do tomorrow latest.

Thanks for the quick reply.

Bye
Norman 

> Am 10.07.2018 um 18:53 schrieb Xuelei Fan :
> 
> Hi Norman,
> 
> It's an interesting user case of the TrustManagerFactory.  Please file a bug.
> 
> Thanks,
> Xuelei
> 
>> On 7/10/2018 9:57 AM, Alan Bateman wrote:
>> Forwarding to security-dev.
>>> On 10/07/2018 17:47, Norman Maurer wrote:
>>> Hi all,
>>> 
>>> I just tried to run netty[1] testsuite with the latest jdk11 EA release 
>>> (21) and saw some class-cast-exception with our custom SSLEngine 
>>> implementation
>>> 
>>> 
>>> Caused by: java.lang.ClassCastException: class 
>>> io.netty.handler.ssl.OpenSslEngine cannot be cast to class 
>>> sun.security.ssl.SSLEngineImpl (io.netty.handler.ssl.OpenSslEngine is in 
>>> unnamed module of loader 'app'; sun.security.ssl.SSLEngineImpl is in module 
>>> java.base of loader 'bootstrap')
>>> at 
>>> java.base/sun.security.ssl.SSLAlgorithmConstraints.(SSLAlgorithmConstraints.java:93)
>>> at 
>>> java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:270)
>>> at 
>>> java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:141)
>>> at 
>>> io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:237)
>>> at 
>>> io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(ReferenceCountedOpenSslContext.java:621)
>>> ... 27 more
>>> 
>>> 
>>> This change seems to be related to:
>>> http://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea
>>> 
>>> I think you miss an instanceof check here in SSLAlgorithmConstraints before 
>>> try to cast to SSLEngineImpl, as otherwise it will be impossible to use 
>>> custom implementations of SSLEngine (which we have in netty) with the 
>>> default TrustManagerFactory.
>>> 
>>> Does this sound correct ? Should I open a bug-report ?
>>> 
>>> Bye
>>> Norman
>>> 
>>> 
>>>