SSL connection issue when calling GRPC service from Alpine Linux Image using Zulu jdk 11

Question

I have a spring boot application which calls a GRPC service using Netty. When I run my code in my local machine (MacOS and zulu jdk without JCE) I am able to connect to the GRPC service.

Note: We are using Oracle JDK 1.8 compiled GRPC client jar

When I build a docker image (Alpine Linux with zulu jdk without JCE) I get below error

    javax.net.ssl|ERROR|37|C7-services-1|2019-09-26 21:18:10.622 GMT|TransportContext.java:312|Fatal (HANDSHAKE_FAILURE): Couldn't kickstart handshaking (
"throwable" : {
  javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
    at java.base/sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:169)
    at java.base/sun.security.ssl.ClientHandshakeContext.<init>(ClientHandshakeContext.java:98)
    at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:216)
    at java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:103)
    at io.netty.handler.ssl.JdkSslEngine.beginHandshake(JdkSslEngine.java:155)
    at io.netty.handler.ssl.SslHandler.handshake(SslHandler.java:1967)
    at io.netty.handler.ssl.SslHandler.startHandshakeProcessing(SslHandler.java:1886)
    at io.netty.handler.ssl.SslHandler.channelActive(SslHandler.java:2021)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:225)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:211)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelActive(AbstractChannelHandlerContext.java:204)
    at io.netty.channel.DefaultChannelPipeline$HeadContext.channelActive(DefaultChannelPipeline.java:1396)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:225)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:211)
    at io.netty.channel.DefaultChannelPipeline.fireChannelActive(DefaultChannelPipeline.java:906)
    at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:311)
    at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:341)
    at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:670)
    at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:617)
    at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:534)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
    at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:906)
    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
    at java.base/java.lang.Thread.run(Thread.java:834)}

)

I see that on my local below cipher suites are present

*   TLS_AES_128_GCM_SHA256
*   TLS_AES_256_GCM_SHA384
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
*   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
*   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
*   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
*   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
*   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
*   TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
*   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
*   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
*   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
*   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
*   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
*   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
*   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
*   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
*   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
*   TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
*   TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
*   TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
*   TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
*   TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
*   TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
*   TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
*   TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
*   TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
*   TLS_EMPTY_RENEGOTIATION_INFO_SCSV
*   TLS_RSA_WITH_AES_128_CBC_SHA
*   TLS_RSA_WITH_AES_128_CBC_SHA256
*   TLS_RSA_WITH_AES_128_GCM_SHA256
*   TLS_RSA_WITH_AES_256_CBC_SHA
*   TLS_RSA_WITH_AES_256_CBC_SHA256
*   TLS_RSA_WITH_AES_256_GCM_SHA384

and in the image i see very few

*   TLS_AES_128_GCM_SHA256
*   TLS_AES_256_GCM_SHA384
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
*   TLS_EMPTY_RENEGOTIATION_INFO_SCSV
*   TLS_RSA_WITH_AES_128_CBC_SHA
*   TLS_RSA_WITH_AES_128_CBC_SHA256
*   TLS_RSA_WITH_AES_128_GCM_SHA256
*   TLS_RSA_WITH_AES_256_CBC_SHA
*   TLS_RSA_WITH_AES_256_CBC_SHA256
*   TLS_RSA_WITH_AES_256_GCM_SHA384

Note: BTW on my local it is choosing TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256

I downgraded my java version to Oracle JDK 1.8 and built the image also with JDK 1.8. Now i was able to resolve the issue with SSL handshake as I can see all the ciphers now available within the image. However I ended up with an issue which is very Alpine Linux.

Caused by: java.lang.IllegalStateException: Could not find TLS ALPN provider; no working netty-tcnative, Conscrypt, or Jetty NPN/ALPN available
    at io.grpc.netty.GrpcSslContexts.defaultSslProvider(GrpcSslContexts.java:258) ~[grpc-netty-1.16.1.jar:1.16.1]
    at io.grpc.netty.GrpcSslContexts.configure(GrpcSslContexts.java:171) ~[grpc-netty-1.16.1.jar:1.16.1]
    at io.grpc.netty.GrpcSslContexts.forClient(GrpcSslContexts.java:120) ~[grpc-netty-1.16.1.jar:1.16.1]
    at com.samsclub.list.core.client.C7ProductCatalogProvider.createChannel(C7ProductCatalogProvider.java:104) ~[sams-list-core-0.0.10-SNAPSHOT.jar:0.0.10-SNAPSHOT]
    at com.samsclub.list.core.client.C7ProductCatalogProvider.init(C7ProductCatalogProvider.java:59) ~[sams-list-core-0.0.10-SNAPSHOT.jar:0.0.10-SNAPSHOT]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_212]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_212]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_212]
    at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_212]
    at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:363) ~[spring-beans-5.1.7.RELEASE.jar:5.1.7.RELEASE]
    at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMet

see this https://github.com/grpc/grpc-java/issues/3336

I really want to be on zulu 11 and wants to call this GRPC service. Should we just get the GRPC client jar compiled with JDK 11.?

My Docker Alpine image config

/app # cat /etc/os-release 
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.10.0
PRETTY_NAME="Alpine Linux v3.10"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"
/app # java -version
openjdk version "11.0.4" 2019-07-16 LTS
OpenJDK Runtime Environment Zulu11.33+15-CA (build 11.0.4+11-LTS)
OpenJDK 64-Bit Server VM Zulu11.33+15-CA (build 11.0.4+11-LTS, mixed mode)

abakhtin · Answer 1 · 2019-09-27T11:52:47.543

1

What do you mean by saying zulu jdk without JCE?

Official zulu jdk is provided with all required crypto libraries and providers. In case of you manually exclude some of the providers or libraries you'll miss corresponding functionality.

For example SunEC crypto provider is responsible for ECDSA and ECDH algorithms implementation. Excluding SunEC from the list of providers or disabling/removing jdk.crypto.ec module, you'll miss all TLS_ECDH_ECDSA_* TLS_ECDHE_ECDSA_* cipher suites. It could be a reason of your TLS handshake failure.

edited Sep 27 '19 at 11:52

answered Sep 27 '19 at 11:00

abakhtin

11
2

JCE (Java Cryptography extension) does not come by default with any jdk download. you need to download it separately. I have not removed anything manually. BTE where we would remove the modules "jdk.crypto.ec module" – Shantanoo K Sep 27 '19 at 15:31

score 0 · Answer 2 · answered Sep 30 '19 at 13:32

Clean alpine docker image with Zulu 11 jdk shows the following:

$ docker run alpn_zulu more /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.10.2
PRETTY_NAME="Alpine Linux v3.10"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"
$ docker run alpn_zulu java -version
openjdk version "11.0.4" 2019-07-16 LTS
OpenJDK Runtime Environment Zulu11.33+15-CA (build 11.0.4+11-LTS)
OpenJDK 64-Bit Server VM Zulu11.33+15-CA (build 11.0.4+11-LTS, mixed mode)
$ docker run alpn_zulu jrunscript -e "java.util.Arrays.asList(javax.net.ssl.SSLServerSocketFactory.getDefault().getSupportedCipherSuites()).stream().forEach(println)"
Warning: Nashorn engine is planned to be removed from a future JDK release
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV

updated my question to have the linux and java config from docker image. — Shantanoo K, Oct 01 '19 at 04:29
Could you run " jrunscript -e "java.util.Arrays.asList(javax.net.ssl.SSLServerSocketFactory.getDefault().getSupportedCipherSuites()).stream().forEach(println)" " and "jrunscript -e "java.util.Arrays.asList(javax.net.ssl.SSLServerSocketFactory.getDefault().getSupportedCipherSuites()).stream().forEach(println)"" commands in alpine image and on the local machine(using zulu11) and compare. if it differs, you have different security configurations in the java.security file — abakhtin, Oct 02 '19 at 16:47

SSL connection issue when calling GRPC service from Alpine Linux Image using Zulu jdk 11

2 Answers2