JDK-8299744 : One component works using SSL whereas other component fails
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 8
  • Priority: P4
  • Status: New
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2022-12-30
  • Updated: 2023-01-06
Related Reports
Relates :  
JDK-8261502 - ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
Relates :  
JDK-8169970 - Java 8u112 32 bits and below sun.security.ec.ECDHKeyAgreement.deriveKey Could not derive key
Description
ADDITIONAL SYSTEM INFORMATION :
OS Name - Linux
OS Architecture - amd64
Jboss - jboss-eap-7.3.3.0
Java - jdk1.8.0_351-amd64

A DESCRIPTION OF THE PROBLEM :
We have two components, one is known as EngineServer and another is PositionKeepingServer, both are configured on the same machine having the same SSL configuration with the same jdk (jdk1.8.0_351-amd64) and jboss (jboss-eap-7.3.3.0) version.
The EngineServer connects successfully with EventServer via SSL connection but the PositionKeepingServer fails using SSL.
Here the EngineServer works with ECDHE ciphers, but the PositionKeepingServer fails. If we configure only the non-ECDHE ciphers in standalone-eventserver.xml, the PositionKeepingServer is able to connect successfully.

---------Exception Details---------
11:07:02 ERROR [stderr] (Thread-2 (ActiveMQ-client-netty-threads)) )
11:07:02 ERROR [org.apache.activemq.artemis.core.client] (Thread-2 (ActiveMQ-client-netty-threads)) AMQ214016: Failed to create netty connection: io.netty.handler.codec.DecoderException: java.lang.IllegalStateException: Could not derive key
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:478) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.9.0.redhat-00019.jar:2.9.0.redhat-00019]
Caused by: java.lang.IllegalStateException: Could not derive key
	at sun.security.ec.ECDHKeyAgreement.deriveKeyNative(ECDHKeyAgreement.java:272)
	at sun.security.ec.ECDHKeyAgreement.lambda$engineGenerateSecret$0(ECDHKeyAgreement.java:171)
	at java.util.Optional.orElseGet(Optional.java:267) [rt.jar:1.8.0_351]
	at sun.security.ec.ECDHKeyAgreement.engineGenerateSecret(ECDHKeyAgreement.java:170)
	at sun.security.ec.ECDHKeyAgreement.engineGenerateSecret(ECDHKeyAgreement.java:202)
	at javax.crypto.KeyAgreement.generateSecret(KeyAgreement.java:652) [jce.jar:1.8.0_351]
	at sun.security.ssl.ECDHKeyExchange$ECDHEKAKeyDerivation.t12DeriveKey(ECDHKeyExchange.java:430) [jsse.jar:1.8.0_351]
	at sun.security.ssl.ECDHKeyExchange$ECDHEKAKeyDerivation.deriveKey(ECDHKeyExchange.java:417) [jsse.jar:1.8.0_351]
	at sun.security.ssl.ECDHClientKeyExchange$ECDHEClientKeyExchangeProducer.produce(ECDHClientKeyExchange.java:415) [jsse.jar:1.8.0_351]
	at sun.security.ssl.ClientKeyExchange$ClientKeyExchangeProducer.produce(ClientKeyExchange.java:65) [jsse.jar:1.8.0_351]
	at sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:420) [jsse.jar:1.8.0_351]
	at sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182) [jsse.jar:1.8.0_351]
	at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:376) [jsse.jar:1.8.0_351]
	at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:479) [jsse.jar:1.8.0_351]
	at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:990) [jsse.jar:1.8.0_351]
	at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:977) [jsse.jar:1.8.0_351]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_351]
	at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:924) [jsse.jar:1.8.0_351]
	at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1528) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1542) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1426) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1253) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1300) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447) [netty-all-4.1.63.Final-redhat-00001.jar:4.1.63.Final-redhat-00001]
	... 14 more
Caused by: java.security.InvalidAlgorithmParameterException
	at sun.security.ec.ECDHKeyAgreement.deriveKey(Native Method)
	at sun.security.ec.ECDHKeyAgreement.deriveKeyNative(ECDHKeyAgreement.java:269)
	... 38 more

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
If the ECDHE ciphers are configured in standalone-eventserver.xml the PositionKeepingServer is not able to connect to EventServer

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
PositionKeepingServer should successfully connect with EventServer even though the ECDHE ciphers are enabled in standalone-eventserver.xml
ACTUAL -
With ECDHE ciphers the PositionKeepingServer fails to connect to EventServer

CUSTOMER SUBMITTED WORKAROUND :
Remove all ECDHE ciphers from standalone-eventserver.xml & allow only the non-ECDHE ciphers

FREQUENCY : always
Comments
Additional information from the submitter: I don't see this issue with the Jboss, this seems to be a problem with the Java SSL component where the ciphering algorithm is failing with the ECDHE. We have come across a similar bug raised which seems to be related but has no further update. https://github.com/nerdclub-tfg/signal-bot/issues/21 https://bugs.openjdk.org/browse/JDK-8169970 https://bugs.openjdk.org/browse/JDK-8261502 In our scenario, one of the component (EngineServer) and another component (PositionKeepingServer) are running on the same machine with the same jdk & JBoss configuration. Here the EngineServer component works fine whereas the PositionKeepingServer component fails with the ECDHE ciphers enabled. May you please confirm why exactly with the same setup, one component(EngineServer) is running successfully whereas the other component(PositionKeepingServer) is failing? Reviewing the attached logs it seems that Java's SSL component fails to parse the same SSL key file for PositionKeepingServer. EngineServer connects successfully with EventServer via SSL connection but the PositionKeepingServer fails using SSL ECDHE ciphers. As a workaround, if we configure only the non-ECDHE ciphers in standalone-eventserver.xml, the PositionKeepingServer is able to connect successfully. Below is the link with the SSL logs having the exception stack trace and the standalone.<server>.xml of EventServer, EngineServer, and PositionKeepingServer. SSL logs Also, let us know where can we track this conversation as a ticketing thread. This is all on the email I am unable to track this incident id on the support portal login.
06-01-2023
Requested a simple reproducer from the submitter.
04-01-2023