Hey Amit, I’ve tried now with Cassandra built from source and running on my laptop, and it behaves as expected (I can toggle ciphers on 1.3) must be something wrong in my container setup.
Thanks for the help there! Sorry for the noise Jackson ________________________________ From: Amit Patel <amit.pa...@euroclear.com> Sent: Wednesday, December 21, 2022 7:26:23 PM To: Fleming, Jackson <jackson.flem...@netapp.com>; user@cassandra.apache.org <user@cassandra.apache.org> Subject: RE: Controlling cipher suites for TLS 1.3 on Cassandra 4 NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. Ah that make sense. I am not using containers, all I did was restrict at java level TLS and configured cipher in Cassandra.yaml (that only support TLS 1.3). Here is my logs: INFO [main] 2022-12-20 16:04:46,246 SSLFactory.java:521 - Internode messaging enabled TLS protocols: TLSv1.2, TLSv1.3 INFO [main] 2022-12-20 16:04:46,246 SSLFactory.java:524 - Internode messaging enabled cipher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 INFO [Messaging-EventLoop-3-3] 2022-12-20 16:04:49,418 OutboundConnection.java:1150 - xxxxxx/10.33.x.xx:7000(/10.33.1.215:33406)->/10.33.x.yy:7000-URGENT_MESSAGES-cdd221a8 successfully connected, version = 12, framing = LZ4, encryption = encrypted(factory=openssl;protocol=TLSv1.3;cipher=TLS_AES_128_GCM_SHA256) Cipher I have used: cipher_suites: [TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384] Amit From: Fleming, Jackson <jackson.flem...@netapp.com> Sent: 20 December 2022 22:39 To: user@cassandra.apache.org; Amit Patel <amit.pa...@euroclear.com> Subject: Re: Controlling cipher suites for TLS 1.3 on Cassandra 4 CAUTION: This email comes from outside Euroclear! Be vigilant! Thanks Amit, Ah ha, I was testing something similar before on Cassandra 3.11 which had those JRE settings, I’ve falsely assumed that those settings were present in my Cassandra 4 environment. I’ve added the following to by jre runtime security file. jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 2048, DSA keySize < 1024, EC keySize < 224, TLSv1, TLSv1.1, SSLv3 jdk.tls.disabledAlgorithms=SSLv3, DSA, RSA keySize < 2048, TLSv1, TLSv1.1 Though unfortunately the results are still the same. I’ve also tried reconfiguring my cluster to use exclusively TLS 1.3 for both internode and client to node communications, such as below, still no success. server_encryption_options: enabled: true protocol: TLSv1.3 cipher_suites: [TLS_AES_256_GCM_SHA384] keystore: /etc/cassandra/keystore.jks truststore: /etc/cassandra/truststore.jks keystore_password: truststore_password: internode_encryption: all require_client_auth: true client_encryption_options: enabled: true keystore: /etc/cassandra/keystore.jks keystore_password: truststore: /etc/cassandra/truststore.jks truststore_password: require_client_auth: false cipher_suites: [TLS_AES_256_GCM_SHA384] protocol: TLSv1.3 I’ve noticed since doing that, it seems no cipher_suite restrictions are being applied now, and I get all the TLS ciphers, even ones for TLS 1.2 and below. o.a.cassandra.security.SSLFactory Native transport enabled TLS protocols: TLSv1.3 INFO o.a.cassandra.security.SSLFactory Native transport enabled cipher suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_PSK_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_PSK_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 So I think the cipher_suites configuration option isn’t working as intended with TLS 1.3 ciphers (it works flawlessly with TLS 1.2 though). I’d like to avoid producing specific java.security files to control cipher suites, as we run Cassandra containers, and we usually bake those into the containers, so that’d be a configuration nightmare for us. Jackson From: Amit Patel via user <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Date: Tuesday, 20 December 2022 at 11:59 pm To: user@cassandra.apache.org<mailto:user@cassandra.apache.org> <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Subject: RE: Controlling cipher suites for TLS 1.3 on Cassandra 4 NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Jackson, I have faced similar issue even if we configure cipher for TLS 1.3 ,I couldn’t control cipher, TLS1 and TLS 1.1 was appearing in scan. I had to restrict (secure) at Java security level. -- There are 2 solutions for this: - First would be by configuring the cipher_suites parameter of the server_encryption_options (for inter node communication) and client_encryption_options (for communication from client to cassandra) to use some cipher suites that are only available in TLS 1.2: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, ... You can have a look at the openssl ciphers manpage to have a list of these cipher suites: https://www.openssl.org/docs/man1.0.2/apps/ciphers.html - Second would be to disable TLSv1.0 and TLSv1.1 at the JRE level. In the jre folder configured to be use by cassandra, edit the file jre/lib/security/java.security and add the TLSv1 and TLSv1.1 protocols to the jdk.tls.disabledAlgorithms,as example: jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048, TLSv1, TLSv1.1 Restart cassandra to apply the change. PS: I have faced issue during restart after the change made in java.security, Cassandra wasn’t starting and logs were not helpful all that was indicating that invalid yaml. So had to troubleshoot it and I have changed setting in java.security as per below. #jdk.tls.disabledAlgorithms=SSLv3, RC4, DH keySize, MD5withRSA < 2048, TLSv1, TLSv1.1 jdk.tls.disabledAlgorithms=SSLv3, DSA, RSA keySize < 2048, TLSv1, TLSv1.1 (changed to this) I hope this can help you to resolve your issue. Kind regards, Amit Patel From: Fleming, Jackson <jackson.flem...@netapp.com<mailto:jackson.flem...@netapp.com>> Sent: 20 December 2022 04:17 To: user@cassandra.apache.org<mailto:user@cassandra.apache.org> Subject: Controlling cipher suites for TLS 1.3 on Cassandra 4 CAUTION: This email comes from outside Euroclear! Be vigilant! Hi All, I’ve hit some trouble recently around restricting ciphers for clients on a test Cassandra 4.0.4 cluster, we’d like to be able to control the Ciphers offered via Cassandra for both TLS 1.2 and 1.3. Was wondering if anyone has had any luck with getting my particular use case to work. I’ve added the following snippit to the Cassandra.yaml file for all the nodes in my cluster client_encryption_options: enabled: true keystore: /etc/cassandra/keystore.jks keystore_password: cassandra truststore: /etc/cassandra/truststore.jks truststore_password: redacted require_client_auth: false cipher_suites: [TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384] accepted_protocols: [TLSv1.2, TLSv1.3] The server correctly only offers two ciphers for TLS 1.2, but it offers 3 for TLS 1.3, if I remove the cipher suite list, the same TLS 1.3 list remains, these log lines are outputted at startup: INFO o.a.cassandra.security.SSLFactory Native transport enabled TLS protocols: TLSv1.2, TLSv1.3 INFO o.a.cassandra.security.SSLFactory Native transport enabled cipher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 If I use testssl.sh (my preferred tester for this kind of stuff) to check the available ciphers per TLS version I get the following output: Testing ciphers per protocol via OpenSSL plus sockets against the server, ordered by encryption strength Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) ----------------------------------------------------------------------------------------------------------------------------- SSLv2 SSLv3 TLS 1 TLS 1.1 TLS 1.2 xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS 1.3 x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384 x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256 x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256 If I remove the references to TLSv1.2 and only use 1.3, I still can’t control the ciphers, the same three are always present for TLSv1.3, regardless of what value I provide for cipher_suites. I am wondering if there is a bug in Cassandra (or more likely Netty) that prevents us from controlling TLS 1.3 ciphers? Or if this is expected behaviour? I apologise in advance if this question has previously been answered, but I cannot find anything in the archives or forums about this. Thanks, Jackson This e-mail message, including any attachments transmitted with it, is CONFIDENTIAL and may contain legally privileged information. This message is intended solely for the use of the individual or entity to whom it is addressed. If you have received this message in error, please notify us immediately and delete it from your system. Please visit our website to read the full disclaimer www.euroclear.com/disclaimer<http://www.euroclear.com/disclaimer> and for Euroclear Group company information www.euroclear.com/aboutus<http://www.euroclear.com/aboutus> This e-mail message, including any attachments transmitted with it, is CONFIDENTIAL and may contain legally privileged information. This message is intended solely for the use of the individual or entity to whom it is addressed. If you have received this message in error, please notify us immediately and delete it from your system. Please visit our website to read the full disclaimer www.euroclear.com/disclaimer and for Euroclear Group company information www.euroclear.com/aboutus
