[
https://issues.apache.org/jira/browse/ZOOKEEPER-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899664#comment-15899664
]
Powell Molleti commented on ZOOKEEPER-236:
------------------------------------------
Hi Abe,
I am more then happy to combine efforts and collaborate. I think the
significant amount of work is testing which is what I am attempting to get it
right in the Trunk patch which also has Netty support when compared to work on
branch-3.5 (this patch).
This patch has support for configuration of for Truststore. Hence if the admin
provides a cert chain that contains the CA(s) or for that matter if the
Truststore contains all the self signed certs it should also work. I did not do
extensive testing for this in this branch (I did this for branch-3.4, hence I
think it should work).
Let me point you to the code and let me know if this can work or is what you
are expecting:
createSSLContext() calls always chain Trustmanagers via X509ChainedTrustManager
class with Truststore manager first i.e ZKX509TrustManager class and dynamic
trust verification via ZKPeerX509TrustManager class.
Client side SSL socket creation:
https://github.com/apache/zookeeper/pull/185/files#diff-74d86ae5e83698ad62aada32dcbe615eR53
Quorum server side SSL socket creation:
https://github.com/apache/zookeeper/pull/185/files#diff-eb0052bc7ed160b8dee226f2ed1bdad2R51
I do think we need consensus here if there is need or want to support dynamic
reconfiguration with SSL in a fault-tolerant way. By which I mean, if I
understand correctly, both the operations of managing the certs (add/remove of
certs) and reconfig() API to change members of a quorum have to be
fault-tolerant. reconfig() is atomic hence no issue there. But then that leaves
managing the certs for the Quorum which is a non trivial problem and there
exists a solution I think that does need support in the guts of ZK. But I think
we can simplify the orchestration of Zookeeper with SSL if it is SSL aware.
CA seems like the best way and simple way to go till such a time arrises when
the CA has to be changed. Also prevalent security considerations recommend
revoking the cert of the Quorum member that is removed. Again how do we
accomplish this in a fault-tolerant way. Hence there is some work still left to
do in CA case.
If we do not consider fault-tolerance for SSL config management or take a
stance that ZK does not have to solve this for the admin then just providing a
Truststore would suffice.
Also regarding the path forward do you think we should aim for a Trunk patch or
patch to 3.5?. Also should we split the effort two phases, first without Netty
and then perhaps bring in Netty etc.
Let me know if I got something wrong and what do you think about bringing in
Netty support for Quorum communication.
Cheers
Powell.
> SSL Support for Atomic Broadcast protocol
> -----------------------------------------
>
> Key: ZOOKEEPER-236
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-236
> Project: ZooKeeper
> Issue Type: New Feature
> Components: quorum, server
> Reporter: Benjamin Reed
> Assignee: Abraham Fine
> Priority: Minor
>
> We should have the ability to use SSL to authenticate and encrypt the traffic
> between ZooKeeper servers. For the most part this is a very easy change. We
> would probably only want to support this for TCP based leader elections.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
