[
https://issues.apache.org/jira/browse/KUDU-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17511581#comment-17511581
]
ASF subversion and git services commented on KUDU-2099:
-------------------------------------------------------
Commit a8fb42dc34e8f1f876db5b26fc3f5eb3196ce854 in kudu's branch
refs/heads/master from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=a8fb42d ]
[security] set minimum TLS protocol version to TSLv1.2
Since support for CentOS 6/RHEL 6, Ubuntu 14, Ubuntu 16, and Debian 8
is dropped since Kudu 1.14 [1], we can bump the minimum required TLS
protocol version up to TLSv1.2 for securing Kudu RPC. That's because
* Supported server-side OSes have OpenSSL of at least version 1.0.1
in their stock distribution, so Kudu servers running on supported
OSes automatically support TLSv1.2
* Kudu Java client requires Java 8+ in runtime since Kudu 1.10 [2],
so Kudu Java clients automatically support TLSv1.2 since then
* As of now, with contemporary Linux OS and updated Java 8 [4], Kudu
servers and clients should be able to use even TLSv1.3.
In addition, this patch updates the list of the preferred TLSv1.2
ciphers, bringing it up-to-date with the "intermediate compatibility"
cipher list of the Mozilla Security Server Side TLS recommendations [3]
(without the DH AES ciphers).
At some point I thought to set TLSv1.2 as the minimum protocol version
only for the server side, keeping TLSv1 as the minimum version for the
client side to allow newer Kudu clients work with Kudu servers running
at no longer supported, beyond-EOL OSes. However, I realized that the
set of TLS ciphers supported by Kudu servers in 1.3 -- 1.14 release
range contained only a couple of non-TLSv1.2 ciphers suites:
* AES128-SHA (TLS_RSA_WITH_AES_128_CBC_SHA)
* AES256-SHA (TLS_RSA_WITH_AES_256_CBC_SHA)
These can be used starting SSLv3, so these are the only ones that Kudu
clients and servers could use if either side didn't support TLSv1.2.
Both use non-GCM ciphers for data encryption, and data transfer rate
with those ciphers is an order of magnitute slower than with TLSv1.2
suites which use GCM ciphers for data encryption. Given all those
facts, I realized it's not worth it keeping such a compatibility around.
The rationale is: if people are still stuck with RHEL/CentOS 6 or other
EOL OS release, they most likely do not care about security and will
be able to use one of the workarounds listed below.
So, with this patch:
* TLSv1.2 is the minimum TLS protocol version that newer Kudu clients
are able to use for secure Kudu RPC. The newer clients are not able
to communicate with servers built and run with OpenSSL of versions
prior to 1.0.1. If such a Kudu cluster is running on a deprecated
OS (e.g., RHEL/CentOS 6.4), the following options are available to
work around the incompatibility:
** use Kudu clients of 1.14 or earlier versions to communicate
with such cluster
** disable RPC encryption and authentication for Kudu RPC, setting
--rpc_authentication=disabled and --rpc_encryption=disabled
for all masters and tablet servers in the cluster to allow the
new client to work with the old cluster
* TLSv1.2 is the minimum TLS protocol version that newer Kudu servers
are able to use for Kudu RPC. The newer servers are not able to
communicate using secure Kudu RPC with Kudu C++ client applications
linked with libkudu_client library built against OpenSSL of versions
prior to 1.0.1 or with Java client applications run with outdated
Java runtime that doesn't support TLSv1.2. The following options
are available to work around this incompatibility:
** customize settings for the --rpc_tls_min_protocol and
--rpc_tls_ciphers flags on all masters and tablet servers
in the cluster, setting --rpc_tls_min_protocol=TLSv1 and
adding TLSv1-capable cipher suites (e.g. AES128-SHA and
AES256-SHA) into the list
** disable RPC encryption and authentication for Kudu RPC, setting
--rpc_authentication=disabled and --rpc_encryption=disabled
for all masters and tablet servers in the cluster to allow such
Kudu clients to work with newer clusters
[1] https://kudu.apache.org/releases/1.14.0/docs/release_notes.html
[2] https://issues.apache.org/jira/browse/KUDU-2099
[3] https://wiki.mozilla.org/Security/Server_Side_TLS
[4] https://www.oracle.com/java/technologies/javase/8all-relnotes.html
Change-Id: I07633a04d3828100f148e5de3905094198d13396
Reviewed-on: http://gerrit.cloudera.org:8080/17268
Reviewed-by: Andrew Wong <[email protected]>
Tested-by: Alexey Serbin <[email protected]>
> Drop Java 7 Support
> -------------------
>
> Key: KUDU-2099
> URL: https://issues.apache.org/jira/browse/KUDU-2099
> Project: Kudu
> Issue Type: Task
> Components: java
> Affects Versions: 1.4.0
> Reporter: Grant Henke
> Assignee: Adar Dembo
> Priority: Major
> Fix For: 1.10.0
>
>
> Java 8 has been out for quite some time and with Java 9 coming we should
> consider dropping Java 7 support. This also would allow us to update some
> libraries that have also decided to move to Java 8 only including Spark 2.2.0
> and Guava 23.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
