Reputation: 31
We are using the Redisson client, which uses netty to connect to a Redis server. With netty 4.1.42.Final, everything worked fine. But after upgrading to netty 4.1.48.Final, TLSv1 ClientHello is sent and therefore not able to connect to the server. Tried specifying TLSv1.2 by setting jdk.tls.client.protocols system property, but netty doesn't seem to be honoring it.
With Java trace turned on, the following is seen in the trace file:
With netty 4.1.48, default protocol has TLSv1 only:
jdk.tls.client.protocols is defined as TLSv1.2
SSLv3 protocol was requested but was not enabled
SUPPORTED: [TLSv1, TLSv1.1, TLSv1.2]
SERVER_DEFAULT: [TLSv1, TLSv1.1, TLSv1.2]
CLIENT_DEFAULT: [TLSv1.2]
IBMJSSE2 will enable CBC protection
12:00:41.624 [redisson-netty-2-9] DEBUG io.netty.handler.ssl.JdkSslContext - Default protocols (JDK): [TLSv1]
With netty 4.1.42, default protocols included TLSv1.2:
jdk.tls.client.protocols is defined as null
SSLv3 protocol was requested but was not enabled
SSLv3 protocol was requested but was not enabled
SUPPORTED: [TLSv1, TLSv1.1, TLSv1.2]
SERVER_DEFAULT: [TLSv1, TLSv1.1, TLSv1.2]
CLIENT_DEFAULT: [TLSv1, TLSv1.1, TLSv1.2]
10:18:00.008 [redisson-netty-2-23] DEBUG io.netty.handler.ssl.JdkSslContext - Default protocols (JDK): [TLSv1.2, TLSv1.1, TLSv1]
netty 4.1.48 trace when jdk.tls.client.protocols system property is not set:
jdk.tls.client.protocols is defined as null
SSLv3 protocol was requested but was not enabled
SSLv3 protocol was requested but was not enabled
SUPPORTED: [TLSv1, TLSv1.1, TLSv1.2]
SERVER_DEFAULT: [TLSv1, TLSv1.1, TLSv1.2]
CLIENT_DEFAULT: [TLSv1, TLSv1.1, TLSv1.2]
IBMJSSE2 will enable CBC protection
09:54:19.626 [redisson-netty-2-25] DEBUG io.netty.handler.ssl.JdkSslContext - Default protocols (JDK): [TLSv1]
java -version output:
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 8.0.5.27 - pwa6480sr5fp27-20190104_01(SR5 FP27))
IBM J9 VM (build 2.9, JRE 1.8.0 Windows 10 amd64-64-Bit Compressed References 20181219_405297 (JIT enabled, AOT enabled)
OpenJ9 - 3f2d574
OMR - 109ba5b
IBM - e2996d1)
JCL - 20190104_01 based on Oracle jdk8u191-b26
Anyone else running into this or know how to fix this?
Thanks!
Upvotes: 2
Views: 13965
Reputation: 116878
Setting jdk.tls.client.protocols system property to TLSv1.2 not working in netty 4.1.48
I'm not 100% sure if our solution will fix you problem but I see IBM in your trace logs. We also were having issues around default cipher being set to TLSv1 in Netty:
io.netty.handler.ssl.JdkSslContext.java:97 - Default protocols (JDK): [TLSv1]
io.netty.handler.ssl.JdkSslContext.java:98 - Default cipher suites (JDK):
[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA]
This turned out to be an issue with the IBM JVM. The following code spits out [TLSv1]
by default under AIX. Not good. Under Redhat and Solaris it spits out [TLSv1, TLSv1.1, TLSv1.2]
.
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, null, null);
String[] supportedProtocols = context.getDefaultSSLParameters().getProtocols();
System.out.println(Arrays.toString(supportedProtocols));
According to this IBM documentation and others, the solution is to add the following property to the JVM:
-Dcom.ibm.jsse2.overrideDefaultTLS=true
I really don't like this answer but I've not found a java.security
file line or other system-wide setting that enables TLSv1.2. Here's the details about the JVM I'm using:
$ java -version
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 8.0.5.0 - pap6480sr5-20170905_01(SR5))
IBM J9 VM (build 2.9, JRE 1.8.0 AIX ppc64-64 Compressed References 20170901_363591
(JIT enabled, AOT enabled)
J9VM - d56eb84
JIT - tr.open_20170901_140853_d56eb84
OMR - b033a01)
JCL - 20170823_01 based on Oracle jdk8u144-b01
Upvotes: 1