Created on 03-19-2015 05:52 AM - last edited on 07-11-2019 09:31 PM by VidyaSargur
We need to disable the TLSv1 cipher to meet a mandated organization security policy.
We've done this by editing the java.security file in the JDK 1.7 JRE's file and disabling other ciphers, RC4 and ECDHE (SSLv3 already disabled)
# Example:
jdk.tls.disabledAlgorithms=SSLv3, RC4, TLSv1, ECDHE
However when we disabled TLSv1 as well the whole stack wasn’t working and getting messages like this (I know it’s a warning)
2015-03-14 13:36:37,389 WARN 257524672@agentServer-0:org.mortbay.log: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 not enabled or not supported
2015-03-14 13:36:37,395 WARN 732163666@scm-web-453:org.mortbay.log: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 not enabled or not supported
2015-03-14 13:36:37,408 WARN 732163666@scm-web-453:org.mortbay.log: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 not enabled or not supported
We've had to re-enable TLSv1 and every thing was working
# Example:
jdk.tls.disabledAlgorithms=SSLv3, RC4, ECDHE
Questions:
1. Can the cloudera platform function with TLSv1 disabled?
2. If it can, what is the recommended way to disable it?
Created 12-08-2015 10:00 PM
Created 07-21-2018 01:09 PM
Hi Harsh,
We are trying to disable TLS1.0 and 1.1. I can find a doc or blog which talks about the documented procedure to disable lower versions of TLS. Could you point me or share the documentation.
Created 07-24-2018 09:26 AM
Thanks for bringing this up. In the future, it would be a good idea to create a new thread rather than continue on an older one like this. When that initial message was posted, I think Cloudera Manager's agent was not able to use anything but TLSv1 (which has since been fixed).
Cloudera is working on documenting this information. For now, I'll add in what we have.
NOTE:
- You must have CDH 5.13.1 or higher in order for these steps to work for you
- We have only tested so far on Redhat and CentOS 6 and 7
----------------------------------------------------------------------------------------------------------------
Java Based Components
The vast majority of the components in the ecosystem are written in Java. This includes Accumulo, Flume, HBase, HDFS, Hive, Kafka, the Keystore Indexer, MapReduce, Oozie, Sentry, Solr, Spark, Sqoop, Yarn, and ZooKeeper. What you need to do is to disable the ciphers on Java which then applied to most of the Java-based services once they are restarted.
Fortunately, there is one universal place to enforce TLS usage for all Java-based components. This is the "java.security" file.
Step 1: Update java.security
NOTE:
HUE
The components of interest in Hue are the Hue load balancer and the Hue servers. We recommend the use of the Hue load balancer because more cipher suites will be available, and there is no issue with Firefox (as described below).
This first change is to the Hue load balancer.
Step 2: The Hue load balancer
On the CM machine, edit /usr/share/cmf/hue/httpd/httpd.conf
Edit the SSLProtocol line to look like this:
SSLProtocol -all +TLSv1.2
NOTE: This step also has to be performed after each CM upgrade.
Step 3: The Hue Server
In CM, add the following to the “Hue Service Advanced Configuration Snippet (Safety Valve) for hue_safety_valve.ini”
[desktop]
ssl_cipher_list=DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2:!SSLv3:!TLSv1
NOTE: The Firefox web browser does not support any cipher suites that overlap with these ciphers. As a result, the Firefox web browser will not load the page and will display the error “SSL_ERROR_NO_CYPHER_OVERLAP”. Chrome, IE, Edge, and Safari do not have this issue, and are fine. This issue does not exist for the Hue Load Balancer above.
Impala
There are two different mechanisms to get TLS 1.2 support, depending on your operating system. On RHEL/CentOS 7, add the following to a CM Configuration Snippet (Safety Valve).
Step 4a: Impala on RHEL/CentOS 7
In CM, add the following parameter in Impala's safety valve: Impala Command Line Argument Advanced Configuration Snippet (Safety Valve)
-ssl_minimum_version=tlsv1.2
On RHEL/CentOS 6, the above flag unfortunately does not work. Add the following instead:
Step 4b: Impala on RHEL/CentOS 6
In CM, add the following parameter in Impala's safety valve: Impala Command Line Argument Advanced Configuration Snippet (Safety Valve)
-ssl_cipher_list=DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2:!SSLv3:!TLS1
NOTE: This solution has the same caveats with respect to Firefox as described above for Hue.
Kudu
There are two ports to configure for Kudu, the rpc protocol port and the webserver protocol port. In CDH 5.13.1 it’s possible to restrict the TLS protocol to TLS 1.2 for the rpc protocol port. This is the port where that all the data travels through. Unfortunately it’s not possible to similarly enforce TLS 1.2 on the web server port in CDH 5.13.1. The traffic that goes over the web server port is of a generally non-sensitive nature - like status.
Like Impala, there are two different solutions depending on the OS version. For RHEL/CentOS 7, do this:
Step 5a: Kudu on RHEL/CentOS 7
In CM, add the following parameter to the “Kudu Service Advanced Configuration Snippet (Safety Valve) for gflagfile”
-rpc_tls_min_protocol=TLSv1.2
On RHEL/CentOS 6, add the following instead:
Step 5b: Kudu on RHEL/CentOS 6
In CM, add the following parameter to the “Kudu Service Advanced Configuration Snippet (Safety Valve) for gflagfile”
-rpc_tls_ciphers=DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2:!SSLv3:!TLSv1
NOTE: Once again, this solution for RHEL/CentOS 6 has the same caveats with respect to Firefox as described above for Hue.
Restart
Now you’ll want to restart everything.
Step 6: Restart
Created 07-11-2019 05:14 PM
Is there any option for the ssl_cipher_list for Cloudera Manager Agents (Port 9000) to support stronger encryptions? We are on CDH 6.2.
Created 07-12-2019 05:04 PM
We have a fix to disable TLSv1 that is already slated for upcoming releases of 6.2.x and 6.3.
I tested, though, and found that the fix still allowed TLSv1_1. After some research I was able to work around a limitation with M2Crypto (which does not support the SSL_OP_NO_TLSv1_1 flag that OpenSSL uses to disable TLSv1_1).
I opened a new Jira internally at Cloudera so we can review it and check it in as needed.
If you are comfortable editing python files, you can test it out yourself.
If that is what you see, TLSv1 and TLSv1.1 connections will not be serviced. The "hang" is OK in this case since Cloudera Manager is the only client of port 9000 and it should be using TLSv1.2.
WARNING: The above steps I tested on my own host, but use at your own risk. If you prefer to not incur the risk, please await an upcoming release that includes the code changes. If for some reason the agent doesn't restart, you can copy the backup file in place and restart the agent to recover. This will not impact data.
Cheers,
Ben
Created 07-12-2019 05:05 PM
Oops; I forgot ot mention that the line to edit should be 95 or close to there.
Also, this would need to be done on all hosts managed by Cloudera Manager as each agent listens on port 9000.
Created 07-15-2019 10:31 AM
This information is incredibly helpful and insightful. We will try this out solution. Thank you very much!
Thanks,
Brett
Created 07-19-2019 04:53 PM
That worked great. I ran this command and the TLS1_1 just hung as you suggested. Thank You!
> openssl s_client -connect <server_name>:9000 -tls1_1 -msg < /dev/null
CONNECTED(00000003)
>>> TLS 1.1 Handshake [length 00a2], ClientHello
01 00 00 9e 03 02 5d 32 57 4b 04 0a af 47 03 90
....
Created 07-22-2019 03:29 PM