Alexey Serbin has posted comments on this change. ( http://gerrit.cloudera.org:8080/17268 )
Change subject: [security] set minimum TLS protocol version to TSLv1.2 ...................................................................... Patch Set 3: (1 comment) http://gerrit.cloudera.org:8080/#/c/17268/3//COMMIT_MSG Commit Message: http://gerrit.cloudera.org:8080/#/c/17268/3//COMMIT_MSG@31 PS3, Line 31: * AES128-SHA (TLS_RSA_WITH_AES_128_CBC_SHA) : * AES256-SHA (TLS_RSA_WITH_AES_256_CBC_SHA) > This might be a silly question, but I'm not sure how the minimum TLS versio The list of available TLS protocols for negotiation from the either side (client or server) is determined by at least the following: * options which are comprised of flags like SSL_OP_NO_TLSv1: the result options are passed to SSL_CTX_set_options() * set of ciphersuites passed to SSL_CTX_set_cipher_list() (or SSL_CTX_set_ciphersuites() for TLSv1.3 ciphersuites) TLS cipher suites have so-called minimum version, meaning the minimum version of the TLS protocol which is able to use them. Say, AES128-SHA (or TLS_RSA_WITH_AES_128_CBC_SHA in IANA notation) has minimum version of SSLv3, meaning that the cipher suite can be used for SSLv3, TLSv1, TLSv1.1. TLSv1.2 (TLSv1.3 is a different beast, and that cipher cannot be used with TLSv1.3). The minimum version for TLS cipher suite is output in the second column if running `openssl ciphers -v`. When a client and a server negotiate a TLS connection, the resulting TLS protocol version and list of ciphers can be only those which available both on the client and the server side. Setting the default list of ciphersuites to what's in this patch plus AES128-SHA:AES256-SHA and setting the minimum TLS version to TLSv1 would allow the new client to: * negotiate TLSv1, TLSv1.1, TLSv1.2, and TLSv1.3 with a new server; if not otherwise constrained from the either side, the result will be TLSv1.3 * only negotiate TLSv1 with the old CentOS6 server which was built with the OpenSSL API workaround, and the only available ciphersuites would be AES128-SHA and AES256-SHA (neither has GCM ciphers and is very slow compared with any modern GCM-capable one) However, that would make the code a bit contrived because of using different settings for the server and the client side. The only benefit would be allowing new clients (1.15 and newer) to communicate with old servers built and running on RHEL/CentOS 6. The data transfer rate for such a case would be abysmal because of using non-GCM ciphers. Also, RHEL/CentOS 6 is EOL and Kudu officially stopped supporting that old platform since version 1.14. -- To view, visit http://gerrit.cloudera.org:8080/17268 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I07633a04d3828100f148e5de3905094198d13396 Gerrit-Change-Number: 17268 Gerrit-PatchSet: 3 Gerrit-Owner: Alexey Serbin <[email protected]> Gerrit-Reviewer: Alexey Serbin <[email protected]> Gerrit-Reviewer: Andrew Wong <[email protected]> Gerrit-Reviewer: Attila Bukor <[email protected]> Gerrit-Reviewer: Grant Henke <[email protected]> Gerrit-Reviewer: Greg Solovyev <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Comment-Date: Fri, 23 Apr 2021 02:05:53 +0000 Gerrit-HasComments: Yes
