Re: Code Review Request, JDK-8210974 : No extensions debug log for ClientHello

[Bradford Wetmore]

Ditto.

Brad


On 9/20/2018 1:03 PM, Jamil Nimeh wrote:

Looks good.

On 9/20/2018 1:02 PM, Xuelei Fan wrote:

Hi,

Please review this simple fix for SunJSSE debug log:
  http://cr.openjdk.java.net/~xuelei/8210974/webrev.00/

The debug log for ClientHello message does not appear in JDK 12. 
Trivial update, no new regression test.


Thanks,
Xuelei

Re: Code Review Request, JDK-8210974 : No extensions debug log for ClientHello

[Jamil Nimeh]

Looks good.

On 9/20/2018 1:02 PM, Xuelei Fan wrote:

Hi,

Please review this simple fix for SunJSSE debug log:
  http://cr.openjdk.java.net/~xuelei/8210974/webrev.00/

The debug log for ClientHello message does not appear in JDK 12. 
Trivial update, no new regression test.


Thanks,
Xuelei

Code Review Request, JDK-8210974 : No extensions debug log for ClientHello

[Xuelei Fan]

Hi,

Please review this simple fix for SunJSSE debug log:
  http://cr.openjdk.java.net/~xuelei/8210974/webrev.00/

The debug log for ClientHello message does not appear in JDK 12. 
Trivial update, no new regression test.


Thanks,
Xuelei

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 >>> > wrote:
 
 Of course not…
 
 ID: 9057280
 
 Thanks
 Norman
 
 
> On 17. Sep 2018, at 19:35, Xuelei Fan  > 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: 
>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 
>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
>> TLS_ECDHE_RSA_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: 
>> SSL_RSA_WITH_3DES_EDE_CBC_SHA
>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 
>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
>> SSL_RSA_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: 
>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 
>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 
>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 
>> 

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

[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 > 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: 
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
TLS_ECDHE_RSA_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: 
SSL_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
SSL_RSA_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: 
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.580 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.580 
CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: 
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 
CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: 
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 

Re: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid ECDH ServerKeyExchange with non-default security provider

[Jaikiran Pai]

Sure, I'll run some tests tomorrow and get more details on whether/how
bouncycastle uses these parameters if they are set after the init
verify/sign calls.

-Jaikiran


On 20/09/18 9:05 PM, Xuelei Fan wrote:
> Thanks for the quick reply, Jaikiran!
>
> Per your diff code, it sounds like a crypto provider implementation
> bugs.  JDK is using a lazy initialization so that the right provider
> get used.  Third party's provider may not do this way.   Would you
> please help to verify if the parameters get used in BouncyCastle if it
> is set after the init method?
>
> Thanks,
> Xuelei
>
> On 9/20/2018 8:22 AM, Jaikiran Pai wrote:
>> Hello Xuelei,
>>
>> It doesn't happen if both the server side and client side use the JDK
>> crypto provider. However if any one side uses a different crypto
>> provider (bouncycastle in this case) then it throws this exception.
>>
>> -Jaikiran
>>
>>
>> On 20/09/18 8:37 PM, Xuelei Fan wrote:
>>> Hi Jaikiran,
>>>
>>> Does it happen if using JDK crypto provider?
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> On 9/20/2018 6:16 AM, Jaikiran Pai wrote:
 Just checking - does this look like a genuine issue? Anything else
 I can
 provide to help reproduce this?

 -Jaikiran


 On 18/09/18 7:06 PM, Jaikiran Pai wrote:
> I have been testing some projects that I know of, with Java 11 RC.
> There's one specific test that has been failing for me, for a while
> now,
> during SSL handshake. Took me a while to narrow it down given the
> size
> of the application and the nature of the exception. The exception
> occurs
> during SSL handshake between a client and a server (both Java and
> both
> using Java 11 RC) and it kept throwing:
>
> Exception in thread "main" javax.net.ssl.SSLHandshakeException:
> Invalid
> ECDH ServerKeyExchange signature
>   at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
>   at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>   at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
>
>
>   at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
>
>
>   at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255)
>
>
>   at
> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.(ECDHServerKeyExchange.java:329)
>
>
>   at
> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeConsumer.consume(ECDHServerKeyExchange.java:535)
>
>
>   at
> java.base/sun.security.ssl.ServerKeyExchange$ServerKeyExchangeConsumer.consume(ServerKeyExchange.java:103)
>
>
>   at
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>
>   at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
>
>
>   at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
>
>
>   at
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
>
>
>   at
> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>   at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>
>
>   at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>
>
>   at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>
>
>   at
> java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
>
>
>   at
> java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
>
>
>   at
> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581)
>
>
>   at
> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)
>
>
>   at
> java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245)
>
>
> ...
>
> This is consistently reproducible if, in the scheme of things:
>
>    1. the cipher suite selected is a ECDHE one. For example
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. The TLS version itself is
> TLSv1.2
> (both server and client).
>
>    2. One side of the client/server, is backed by BouncyCastle as the
> security provider (very specifically for SignatureSpi).
>
> Assuming the server side is using BouncyCastle provider, what's
> happening is that during the handshake, the server side uses the
> RSASSA-PSS algorithm, backed by this provider and writes out the
> signature. 

Re: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid ECDH ServerKeyExchange with non-default security provider

[Xuelei Fan]

Thanks for the quick reply, Jaikiran!

Per your diff code, it sounds like a crypto provider implementation 
bugs.  JDK is using a lazy initialization so that the right provider get 
used.  Third party's provider may not do this way.   Would you please 
help to verify if the parameters get used in BouncyCastle if it is set 
after the init method?


Thanks,
Xuelei

On 9/20/2018 8:22 AM, Jaikiran Pai wrote:

Hello Xuelei,

It doesn't happen if both the server side and client side use the JDK
crypto provider. However if any one side uses a different crypto
provider (bouncycastle in this case) then it throws this exception.

-Jaikiran


On 20/09/18 8:37 PM, Xuelei Fan wrote:

Hi Jaikiran,

Does it happen if using JDK crypto provider?

Thanks,
Xuelei

On 9/20/2018 6:16 AM, Jaikiran Pai wrote:

Just checking - does this look like a genuine issue? Anything else I can
provide to help reproduce this?

-Jaikiran


On 18/09/18 7:06 PM, Jaikiran Pai wrote:

I have been testing some projects that I know of, with Java 11 RC.
There's one specific test that has been failing for me, for a while
now,
during SSL handshake. Took me a while to narrow it down given the size
of the application and the nature of the exception. The exception
occurs
during SSL handshake between a client and a server (both Java and both
using Java 11 RC) and it kept throwing:

Exception in thread "main" javax.net.ssl.SSLHandshakeException: Invalid
ECDH ServerKeyExchange signature
  at
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
  at
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
  at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)

  at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)

  at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255)

  at
java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.(ECDHServerKeyExchange.java:329)

  at
java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeConsumer.consume(ECDHServerKeyExchange.java:535)

  at
java.base/sun.security.ssl.ServerKeyExchange$ServerKeyExchangeConsumer.consume(ServerKeyExchange.java:103)

  at
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
  at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)

  at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)

  at
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)

  at
java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
  at
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)

  at
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)

  at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)

  at
java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)

  at
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)

  at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581)

  at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)

  at
java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245)

...

This is consistently reproducible if, in the scheme of things:

   1. the cipher suite selected is a ECDHE one. For example
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. The TLS version itself is
TLSv1.2
(both server and client).

   2. One side of the client/server, is backed by BouncyCastle as the
security provider (very specifically for SignatureSpi).

Assuming the server side is using BouncyCastle provider, what's
happening is that during the handshake, the server side uses the
RSASSA-PSS algorithm, backed by this provider and writes out the
signature. The client side uses SunRsaSign (default provider) and tries
to verify this RSASSA-PSS signature and fails with that above
exception.
FWIW, I don't believe the signature algorithm matters as long as the
cipher is ECDHE backed and the client and server side use a different
security provider.

All this works perfectly fine when both the sides use the default
provider and bouncycastle isn't involved.

I was able to get this reproducible in a very simple server/client
standalone program. I think this can even be demonstrated in a jtreg
test but I don't have enough experience with it to see how to trigger a
server in a separate JVM and then use a client for testing. The
reproducer code (Server.java and Client.java) is at the end of this
mail
along with instructions on how to reproduce it.

I was also able to narrow down this issue down to a specific part of
the
JDK code. sun.security.ssl.SignatureScheme#getSignature[1] 

Re: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid ECDH ServerKeyExchange with non-default security provider

[Jaikiran Pai]

Hello Xuelei,

It doesn't happen if both the server side and client side use the JDK
crypto provider. However if any one side uses a different crypto
provider (bouncycastle in this case) then it throws this exception.

-Jaikiran


On 20/09/18 8:37 PM, Xuelei Fan wrote:
> Hi Jaikiran,
>
> Does it happen if using JDK crypto provider?
>
> Thanks,
> Xuelei
>
> On 9/20/2018 6:16 AM, Jaikiran Pai wrote:
>> Just checking - does this look like a genuine issue? Anything else I can
>> provide to help reproduce this?
>>
>> -Jaikiran
>>
>>
>> On 18/09/18 7:06 PM, Jaikiran Pai wrote:
>>> I have been testing some projects that I know of, with Java 11 RC.
>>> There's one specific test that has been failing for me, for a while
>>> now,
>>> during SSL handshake. Took me a while to narrow it down given the size
>>> of the application and the nature of the exception. The exception
>>> occurs
>>> during SSL handshake between a client and a server (both Java and both
>>> using Java 11 RC) and it kept throwing:
>>>
>>> Exception in thread "main" javax.net.ssl.SSLHandshakeException: Invalid
>>> ECDH ServerKeyExchange signature
>>>  at
>>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
>>>  at
>>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>>>  at
>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
>>>
>>>  at
>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
>>>
>>>  at
>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255)
>>>
>>>  at
>>> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.(ECDHServerKeyExchange.java:329)
>>>
>>>  at
>>> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeConsumer.consume(ECDHServerKeyExchange.java:535)
>>>
>>>  at
>>> java.base/sun.security.ssl.ServerKeyExchange$ServerKeyExchangeConsumer.consume(ServerKeyExchange.java:103)
>>>
>>>  at
>>> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>>>  at
>>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
>>>
>>>  at
>>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
>>>
>>>  at
>>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
>>>
>>>  at
>>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>>>  at
>>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>>>
>>>  at
>>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>>>
>>>  at
>>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>>>
>>>  at
>>> java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
>>>
>>>  at
>>> java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
>>>
>>>  at
>>> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581)
>>>
>>>  at
>>> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)
>>>
>>>  at
>>> java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245)
>>>
>>> ...
>>>
>>> This is consistently reproducible if, in the scheme of things:
>>>
>>>   1. the cipher suite selected is a ECDHE one. For example
>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. The TLS version itself is
>>> TLSv1.2
>>> (both server and client).
>>>
>>>   2. One side of the client/server, is backed by BouncyCastle as the
>>> security provider (very specifically for SignatureSpi).
>>>
>>> Assuming the server side is using BouncyCastle provider, what's
>>> happening is that during the handshake, the server side uses the
>>> RSASSA-PSS algorithm, backed by this provider and writes out the
>>> signature. The client side uses SunRsaSign (default provider) and tries
>>> to verify this RSASSA-PSS signature and fails with that above
>>> exception.
>>> FWIW, I don't believe the signature algorithm matters as long as the
>>> cipher is ECDHE backed and the client and server side use a different
>>> security provider.
>>>
>>> All this works perfectly fine when both the sides use the default
>>> provider and bouncycastle isn't involved.
>>>
>>> I was able to get this reproducible in a very simple server/client
>>> standalone program. I think this can even be demonstrated in a jtreg
>>> test but I don't have enough experience with it to see how to trigger a
>>> server in a separate JVM and then use a client for testing. The
>>> reproducer code (Server.java and Client.java) is at the end of this
>>> mail
>>> along with instructions on how to reproduce it.
>>>
>>> I was also able to narrow down this issue down to a specific part of
>>> the
>>> JDK code. sun.security.ssl.SignatureScheme#getSignature[1] inits the

Re: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid ECDH ServerKeyExchange with non-default security provider

[Xuelei Fan]

Hi Jaikiran,

Does it happen if using JDK crypto provider?

Thanks,
Xuelei

On 9/20/2018 6:16 AM, Jaikiran Pai wrote:

Just checking - does this look like a genuine issue? Anything else I can
provide to help reproduce this?

-Jaikiran


On 18/09/18 7:06 PM, Jaikiran Pai wrote:

I have been testing some projects that I know of, with Java 11 RC.
There's one specific test that has been failing for me, for a while now,
during SSL handshake. Took me a while to narrow it down given the size
of the application and the nature of the exception. The exception occurs
during SSL handshake between a client and a server (both Java and both
using Java 11 RC) and it kept throwing:

Exception in thread "main" javax.net.ssl.SSLHandshakeException: Invalid
ECDH ServerKeyExchange signature
     at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
     at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
     at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
     at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
     at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255)
     at
java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.(ECDHServerKeyExchange.java:329)
     at
java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeConsumer.consume(ECDHServerKeyExchange.java:535)
     at
java.base/sun.security.ssl.ServerKeyExchange$ServerKeyExchangeConsumer.consume(ServerKeyExchange.java:103)
     at
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
     at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
     at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
     at
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
     at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
     at
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
     at
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
     at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
     at
java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
     at
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
     at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581)
     at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)
     at
java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245)
...

This is consistently reproducible if, in the scheme of things:

  1. the cipher suite selected is a ECDHE one. For example
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. The TLS version itself is TLSv1.2
(both server and client).

  2. One side of the client/server, is backed by BouncyCastle as the
security provider (very specifically for SignatureSpi).

Assuming the server side is using BouncyCastle provider, what's
happening is that during the handshake, the server side uses the
RSASSA-PSS algorithm, backed by this provider and writes out the
signature. The client side uses SunRsaSign (default provider) and tries
to verify this RSASSA-PSS signature and fails with that above exception.
FWIW, I don't believe the signature algorithm matters as long as the
cipher is ECDHE backed and the client and server side use a different
security provider.

All this works perfectly fine when both the sides use the default
provider and bouncycastle isn't involved.

I was able to get this reproducible in a very simple server/client
standalone program. I think this can even be demonstrated in a jtreg
test but I don't have enough experience with it to see how to trigger a
server in a separate JVM and then use a client for testing. The
reproducer code (Server.java and Client.java) is at the end of this mail
along with instructions on how to reproduce it.

I was also able to narrow down this issue down to a specific part of the
JDK code. sun.security.ssl.SignatureScheme#getSignature[1] inits the
Signature instance for either signing or verifying. However it sets up
the signature parameters _after_ the init is done and in fact, there's
an explicit note[2] stating what/why it's doing it there. I admit, I
don't have much knowledge of the Java SSL parts and none in these
internal details and don't understand the details of that implementation
notes. However, just to try it out, I switched the order of it by using
this local patch:

diff -r fbb71a7edc1a
src/java.base/share/classes/sun/security/ssl/SignatureScheme.java
---
a/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java
Sat Aug 25 20:16:43 2018 +0530
+++
b/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java
Tue Sep 18 

Re: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid ECDH ServerKeyExchange with non-default security provider

[Jaikiran Pai]

Just checking - does this look like a genuine issue? Anything else I can
provide to help reproduce this?

-Jaikiran


On 18/09/18 7:06 PM, Jaikiran Pai wrote:
> I have been testing some projects that I know of, with Java 11 RC.
> There's one specific test that has been failing for me, for a while now,
> during SSL handshake. Took me a while to narrow it down given the size
> of the application and the nature of the exception. The exception occurs
> during SSL handshake between a client and a server (both Java and both
> using Java 11 RC) and it kept throwing:
>
> Exception in thread "main" javax.net.ssl.SSLHandshakeException: Invalid
> ECDH ServerKeyExchange signature
>     at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
>     at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>     at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
>     at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
>     at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255)
>     at
> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.(ECDHServerKeyExchange.java:329)
>     at
> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeConsumer.consume(ECDHServerKeyExchange.java:535)
>     at
> java.base/sun.security.ssl.ServerKeyExchange$ServerKeyExchangeConsumer.consume(ServerKeyExchange.java:103)
>     at
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
>     at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
>     at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
>     at
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
>     at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>     at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>     at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>     at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>     at
> java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
>     at
> java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
>     at
> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581)
>     at
> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)
>     at
> java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245)
> ...
>
> This is consistently reproducible if, in the scheme of things:
>
>  1. the cipher suite selected is a ECDHE one. For example
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. The TLS version itself is TLSv1.2
> (both server and client).
>
>  2. One side of the client/server, is backed by BouncyCastle as the
> security provider (very specifically for SignatureSpi).
>
> Assuming the server side is using BouncyCastle provider, what's
> happening is that during the handshake, the server side uses the
> RSASSA-PSS algorithm, backed by this provider and writes out the
> signature. The client side uses SunRsaSign (default provider) and tries
> to verify this RSASSA-PSS signature and fails with that above exception.
> FWIW, I don't believe the signature algorithm matters as long as the
> cipher is ECDHE backed and the client and server side use a different
> security provider.
>
> All this works perfectly fine when both the sides use the default
> provider and bouncycastle isn't involved.
>
> I was able to get this reproducible in a very simple server/client
> standalone program. I think this can even be demonstrated in a jtreg
> test but I don't have enough experience with it to see how to trigger a
> server in a separate JVM and then use a client for testing. The
> reproducer code (Server.java and Client.java) is at the end of this mail
> along with instructions on how to reproduce it.
>
> I was also able to narrow down this issue down to a specific part of the
> JDK code. sun.security.ssl.SignatureScheme#getSignature[1] inits the
> Signature instance for either signing or verifying. However it sets up
> the signature parameters _after_ the init is done and in fact, there's
> an explicit note[2] stating what/why it's doing it there. I admit, I
> don't have much knowledge of the Java SSL parts and none in these
> internal details and don't understand the details of that implementation
> notes. However, just to try it out, I switched the order of it by using
> this local patch:
>
> diff -r fbb71a7edc1a
> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java
> ---
> a/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java   
> Sat Aug 25 20:16:43 2018 +0530
> +++
>