Overview
This article provides instructions on how to configure DSE nodes to only use the TLSv1.2 protocol for SSL connections. Please note that starting in Java 1.8_191, TLSv1 and TLSv1.1 are disabled by default. Please refer to JDK-8202343 in the release announcement.
Applies to
- DataStax Enterprise 5.0.x
- DataStax Enterprise 5.1.x
- DataStax Enterprise 6.0.x
- DataStax Enterprise 6.7.x
- DataStax Enterprise 6.8.x
Background
DataStax Enterprise clusters allow both TLSv1.0 and TLSv1.1 protocols for SSL connections by default, with TLSv1.2 protocol being a configurable option. For organizations with a strict security requirement which only allows TLSv1.2, follow one of the options provided here.
Option A - Limit ciphers
For this option, the solution is to configure DSE nodes to only use ciphers supported by the TLSv1.2 protocol (see the OpenSSL ciphers page in the reference at the bottom of this article). Any clients attempting to connect with a non-configured cipher will get rejected.
Step A1 - On the first DSE node, update the server_encryption_options section in the cassandra.yaml to only have TLSv1.2 ciphers. For example:
cipher_suites: [TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, ... ]
Step A2 - On the same node, update the client_encryption_options section to use the same ciphers.
Step A3 - Restart DSE for the changes to take effect.
Step A4 - Repeat all the steps on the next node, one at a time, until all nodes have been reconfigured.
Option B - Reconfigure Java
For this option, the solution is to disable the use of TLSv1 and TLSv1.1 protocols within Java's security framework.
WARNING - This procedure will disable both protocols for all Java applications running on the server. If there are other applications which require TLSv1 or TLSv1.1 protocols, implement Option A above instead.
Step B1 - On the first DSE node, update the jre/lib/security/java.security configuration file and add the TLSv1 and TLSv1.1 protocols to the jdk.tls.disabledAlgorithms property. For example:
jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048, TLSv1, TLSv1.1
Step B2 - Restart DSE for the change to take effect.
Step B3 - Repeat all the steps on the next node, one at a time, until all nodes have been reconfigured.
Configure cqlsh
By default, cqlsh uses the TLSv1.0 protocol. Since TLSv1.0 is disabled on the nodes, it is necessary to reconfigure the clients on each node otherwise users will receive an error on the console similar to this:
Connection error: ('Unable to connect to any servers', {'10.1.2.3': error(1, "Tried connecting to [('10.1.2.3', 9042)]. \
Last error: _ssl.c:510: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number")})
Here is an example corresponding entry in the system.log of the relevant node:
INFO [epollEventLoopGroup-1-2] 2018-02-05 12:34:56,789 Message.java:666 - Unexpected exception during request; \
channel = [id: 0x3d95a8ed, L:/10.1.2.3:9042 ! R:/10.1.2.3:57610]
javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 not enabled or not supported
cqlsh was written in Python and the SSL socket version which includes support for the TLSv1.2 protocol is SSLv23.
In the cqlshrc configuration file, set the SSL version in the [ssl] section. For example:
[ssl] certfile = /home/brendanc/certs/client.pem validate = false version = SSLv23
Troubleshooting
Use the openssl s_client command to test connectivity to a server using the TLSv1.2 protocol. For example:
$ openssl s_client -connect 10.1.2.3:9042 -tls1_2
CONNECTED(00000003)
depth=1 C = US, O = DataStax, OU = bc, CN = rootCa
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=US/O=DataStax/OU=ssl/CN=10.1.2.3
i:/C=US/O=DataStax/OU=bc/CN=rootCa
1 s:/C=US/O=DataStax/OU=bc/CN=rootCa
i:/C=US/O=DataStax/OU=bc/CN=rootCa
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIC/zCCAecCCQChH9tpTHiY8jANBgkqhkiG9w0BAQUFADA+MQswCQYDVQQGEwJV
<snip>
-----END CERTIFICATE-----
subject=/C=US/O=DataStax/OU=ssl/CN=10.1.2.3
issuer=/C=US/O=DataStax/OU=bc/CN=rootCa
---
No client certificate CA names sent
---
SSL handshake has read 2102 bytes and written 501 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 5A7A13CAD9D47BD6F4044E5047E65BD712C3C464107FCEA9E21161E40A07AF3E
Session-ID-ctx:
Master-Key: E3DD2B8804CC1D157B60BD515655E0207B91CB141840D26C571899B004013F47C4B2AA7170234CBDCBC3B66FDF7F648F
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1517949898
Timeout : 7200 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
To check that the server is only accepting requests with the TLSv1.2 protocol, use the -no_tls_1_2 flag. For example:
$ openssl s_client -connect 10.1.2.3:9042 -no_tls1_2
CONNECTED(00000003)
140339530618528:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:340:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1517950087
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
See also
External doc - OpenSSL ciphers manpage