Java 13 Compatibility -- ClassCastException BCXDHPublicKey to XECPublicKey

[bstansberry]

In WildFly we updated our master branch to use 1.64 a couple weeks ago and I've noticed that since then our nightly job running our testsuite against JDK 13 is showing failures due to a CCE.

@spadou noted the same problem in a comment on #589 -- #589 (comment)

Apologies if this is a duplicate.

The stack trace:

2019-11-02 02:46:07,835 ERROR [io.undertow.request] (default I/O-2) Closing SSLConduit after exception on handshake: java.lang.ClassCastException: class org.bouncycastle.jcajce.provider.asymmetric.edec.BCXDHPublicKey cannot be cast to class java.security.interfaces.XECPublicKey (org.bouncycastle.jcajce.provider.asymmetric.edec.BCXDHPublicKey is in unnamed module of loader 'org.bouncycastle@1.64' @4c03a2af; java.security.interfaces.XECPublicKey is in module java.base of loader 'bootstrap')
	at java.base/sun.security.ssl.XDHKeyExchange$XDHEPossession.<init>(XDHKeyExchange.java:108)
	at java.base/sun.security.ssl.NamedGroup$XDHFunctions.createPossession(NamedGroup.java:750)
	at java.base/sun.security.ssl.NamedGroup.createPossession(NamedGroup.java:390)
	at java.base/sun.security.ssl.ECDHKeyExchange$ECDHEPossessionGenerator.createPossession(ECDHKeyExchange.java:265)
	at java.base/sun.security.ssl.SSLKeyExchange$T12KeyAgreement.createPossession(SSLKeyExchange.java:352)
	at java.base/sun.security.ssl.SSLKeyExchange.createPossessions(SSLKeyExchange.java:84)
	at java.base/sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuite(ServerHello.java:442)
	at java.base/sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(ServerHello.java:296)
	at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:440)
	at java.base/sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(ClientHello.java:1120)
	at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:853)
	at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:812)
	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
	at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1260)
	at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1247)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
	at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1192)
	at io.undertow.core@2.0.27.Final//io.undertow.protocols.ssl.SslConduit$5.run(SslConduit.java:1072)
	at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
	at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
	at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
	at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
	at java.base/java.lang.Thread.run(Thread.java:830)

[brcolow]

I am also seeing this same problem now when not using the workaround noted in #589.

[bcgit]

Okay, I think this is finally working - we have a multi-release jar that seems to do the job. See https://www.bouncycastle.org/betas

Let us know how it goes.

[bstansberry]

Great! We're looking into how to test the beta.

[Wayonb]

I was hitting this issue also with 1.64. I upgraded to the beta version now hitting this exception because the key type is XDHPublicKeyImpl.

    } else if (!(key instanceof BCXDHPublicKey)) {
        throw new InvalidKeyException("cannot identify XDH private key");
    } else {

key value:
algorithm = 1.3.101.110, unparsed keybits =
0000: 8B B6 39 75 38 A2 03 4A 6E FC CF C6 1A ED 77 09 ..9u8..Jn.....w.
0010: 1B 0F F5 C5 13 B6 AA 37 D9 75 D2 3F 81 39 C0 73 .......7.u.?.9.s

Caused by: javax.net.ssl.SSLHandshakeException: Could not generate secret
at java.base/sun.security.ssl.KAKeyDerivation.t13DeriveKey(KAKeyDerivation.java:128)
at java.base/sun.security.ssl.KAKeyDerivation.deriveKey(KAKeyDerivation.java:63)
at java.base/sun.security.ssl.ServerHello$T13ServerHelloConsumer.consume(ServerHello.java:1290)
at java.base/sun.security.ssl.ServerHello$ServerHelloConsumer.onServerHello(ServerHello.java:1005)
at java.base/sun.security.ssl.ServerHello$ServerHelloConsumer.consume(ServerHello.java:893)
at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422)
at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1460)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1368)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:437)
at io.nem.symbol.sdk.infrastructure.directconnect.auth.TlsSocket.lambda$createSocket$0(TlsSocket.java:60)
at io.nem.symbol.core.utils.ExceptionUtils.propagate(ExceptionUtils.java:78)
... 69 more
Caused by: java.security.InvalidKeyException: cannot identify XDH private key
at org.bouncycastle.jcajce.provider.asymmetric.edec.KeyAgreementSpi.engineDoPhase(KeyAgreementSpi.java:158)
at java.base/javax.crypto.KeyAgreement.doPhase(KeyAgreement.java:579)
at java.base/sun.security.ssl.KAKeyDerivation.t13DeriveKey(KAKeyDerivation.java:104)
... 83 more

[bcgit]

How is the key being generated?

[Wayonb]

The key is the peer public key and it was created using openssl below. The server is c++ with tls 1.3 that uses openssl and boost.

openssl genpkey -out "${1}.key.pem" -outform PEM -algorithm ed25519

Note: This problem only happens when I move the BouncyCastleProvider preference up.

Security.insertProviderAt(new BouncyCastleProvider(), 2);

[bcgit]

Actually, what I meant was how is the key been created in Java? The stack trace indicates a non BC key is being passed to the BC key agreement function. Although in this case it might be possible to work around, strictly speaking keys need to be used with the provider they are generated with.

[Wayonb]

Some more debugging I realized that sslcontext was incorrect and that is why the peer keys got created with the default provider. I updated the sslcontext to also use BCJSSE as the provider and it works now. The down fall is that I am limited to TLSv1.2. Any updates on TLSv1.3 support? Thanks.

[bcgit]

We're working on it. Hoping for 1.66.

[Wayonb]

When you have tls 1.3 beta support, I am more than willing to help tests. Thanks.