FAQ - How to force SSL TLSv1.2 protocol with DSE

Overview

This article provides instructions on how to configure DSE nodes to only use the TLSv1.2 protocol for SSL connections.

Applies to

• DataStax Enterprise 5.0.x
• DataStax Enterprise 5.1.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