[ https://issues.apache.org/jira/browse/KUDU-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733203#comment-17733203 ]
ASF subversion and git services commented on KUDU-1921: ------------------------------------------------------- Commit 6b2077e48e1e96cf6520db09ddd8c2d3ca97334d in kudu's branch refs/heads/master from Alexey Serbin [ https://gitbox.apache.org/repos/asf?p=kudu.git;h=6b2077e48 ] [rpc] clean up JWT-related client-side negotiation code Since now there is an API to add a trusted TLS certificate into the chain of trusted certificates of a Kudu C++ client application, the test-only flag --jwt_client_require_trusted_tls_cert is no longer needed. This patch removes the flag along with corresponding test scenario. Correspondingly, the client now verifies the server's TLS certificate during TLS handshake since there isn't a case when a client would send out its JWT to a server it doesn't trust once the --jwt_client_require_trusted_tls_cert test-only flag is removed. This patch also adds an extra logging about a connection negotiation condition when the client has a JWT, but it doesn't trust the server's TLS certificate. In addition, I took the liberty of removing a few TODOs related to KUDU-1921 since the referred functionality has already been implemented. Change-Id: I85574ed05396fcf3740d9d068afa524cf125f5ff Reviewed-on: http://gerrit.cloudera.org:8080/20076 Reviewed-by: Attila Bukor <abu...@apache.org> Tested-by: Kudu Jenkins > Add ability for clients to require authentication/encryption > ------------------------------------------------------------ > > Key: KUDU-1921 > URL: https://issues.apache.org/jira/browse/KUDU-1921 > Project: Kudu > Issue Type: Improvement > Components: client, security > Affects Versions: 1.3.0 > Reporter: Todd Lipcon > Assignee: Attila Bukor > Priority: Critical > Labels: roadmap-candidate > Fix For: 1.16.0 > > > Currently, the clients always operate in "optional" mode for authentication > and encryption. This means that they are vulnerable to downgrade attacks by a > MITM. We should provide APIs so that clients can be configured to prohibit > downgrade when connecting to clusters they know to be secure. -- This message was sent by Atlassian Jira (v8.20.10#820010)