Hi! Disclaimer: I am not a crypto expert, so I may well be missing something, please correct me wherever I am wrong.
As I was working on some TLS 1.3 issues, I've checked X509Util, and I think that HBase is trying to do more than it should wrt TLS configuration. X509Util originated (and is still present) in Zookeeper, and it resorted to manual cipher management to optimize for performance on different versions. That Java 8/9 optimization is completely irrelevant for Hbase 3+ (but I suspect that it is also irrelevant for current Java 8 versions) I think that manually managing the ciphers and algorithms is missing the point. The JDK already has defaults, and it provides the jdk.tls.disabledAlgorithms and the java.security file to tune SSL. IMO any product / organization that needs this level of control over TLS settings will already have its JVMs set up for them, or have set the relevant system properties already, and having a separate HBase level mechanism only adds unnecessary complexity. There is also a discussion on a ZK PR https://github.com/apache/zookeeper/pull/1919 which discusses this issue ( and which has inspired me to start this discussion) This is of course complicated by netty tcnative, so we may (or may not, I have not looked very deep into it) need to some processing of the default ciphers, but the idea is to try to avoid meddling in the JVM / Netty defaults unless necessary, or explicitly configured. My proposal is: For each of *hbase.rpc.tls.enabledProtocols *, *hbase.rpc.tls.ciphersuites* and *hbase.rpc.tls.protocol: *Unless the property is explicitly set use the Netty / JVM defaults. This includes removing the obsolete JVM version specific cipher list manipulation. If any of the three properties are set, simply call the appropriate setters on the Netty builder with them, without further processing (again, unless necessary for OpenSSL support) AFAIU, we have some code to check if the reported available ciphers can actually be used (i.e. they are not disabled by security settings/system properties). I would expect the TLS implementation to be intelligent enough not to offer these if they wouldn't work anyway, so I would also consider removing that logic (after testing). Istvan
