Mailing-List: contact dev-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zookeeper.apache.org
Date: Wed, 15 Mar 2017 18:14:42 +0000 (UTC)
From: "Abraham Fine (JIRA)" <jira@apache.org>
To: dev@zookeeper.apache.org
Message-ID: <JIRA.12409148.1227561459000.29469.1489601682329@Atlassian.JIRA>
In-Reply-To: <JIRA.12409148.1227561459000@Atlassian.JIRA>
References: <JIRA.12409148.1227561459000@Atlassian.JIRA> <JIRA.12409148.1227561459207@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (ZOOKEEPER-236) SSL Support for Atomic
 Broadcast protocol
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 15 Mar 2017 18:14:52 -0000


    [ https://issues.apache.org/jira/browse/ZOOKEEPER-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926674#comment-15926674 ] 

Abraham Fine edited comment on ZOOKEEPER-236 at 3/15/17 6:14 PM:
-----------------------------------------------------------------

[~geek101]-

bq. One way to go is to minimize changes to Leader.java, Follower.java, Learner.java etc
I agree. That will make understanding those classes much easier

bq.  I do not think it mentions this should be not be done at cert verification time nor should we allow exchange of application bits when the certificate is not what we expected it to be.
So the issue is more zookeeper specific I think. Imagine the case where, and I know this is very contrived but I think the principal is valid, we have 3 zk servers all running on the same host with different ports. We have 3 dns records pointing to this machine with different names, say zk1, zk2, and zk3. Each zkX has a certificate with the zkX common name. Our zookeeper configuration identifies these servers by the correct name server.1=zk1... When one of these servers connects to the server socket on the other I do not think it is possible for the "server" to tell which zkX connected until the sid is read from the socket unless we want to start doing reverse dns lookups. I would rather just use the hostname we already know about. That is why I think we cannot do hostname verification in the trust manager.Please let me know if I am missing something.

bq. I am fine with either OSCP or CRL verification as long as the admin is aware of how this affects the latency of session setup and reliability of the Quorum since they are all perhaps talking to one entity(hopefully not) for this to work.
I agree. We need to document this drawbacks clearly.

bq. Also I noticed the ZOOKEEPER-2184 could be addressed by some of my plumbing changes that pass the configured hostname around along with the resolved ip address. 
There is an active PR for this so I don't think we need to address it in this patch.

bq. It is best to combine the PRs into one so we can collaborate and increase the velocity.
I agree.

bq.  I would like to suggest that we use X509ExtendedTrustManager
If the concerns I listed above with hostname verification can be addressed I would be open to this.

bq. I would like to keep the BC helper code
What do you mean by bc helper code?

bq.  I lean towards just changing Socket() calls to something else but not adding any more code to Leader.java, Follower.java, Learner.java etc.
Sounds like a good idea. Once we get the implementation details flushed out there will be plenty of refactoring to clean this stuff up.

Thanks,
Abe


was (Author: abrahamfine):
[~geek101]-

bq. One way to go is to minimize changes to Leader.java, Follower.java, Learner.java etc
I agree. That will make understanding those classes much easier

bq.  I do not think it mentions this should be not be done at cert verification time nor should we allow exchange of application bits when the certificate is not what we expected it to be.
So the issue is more zookeeper specific I think. Imagine the case where, and I know this is very contrived but I think the principal is valid, we have 3 zk servers all running on the same host with different ports. We have 3 dns records pointing to this machine with different names, say zk1, zk2, and zk3. Each zkX has a certificate with the zkX common name. Our zookeeper configuration identifies these servers by the correct name server.1=zk1... When one of these servers connects to the server socket on the other I do not think it is possible for the "server" to tell which zkX connected until the sid is read from the socket. That is why I think we cannot do hostname verification in the trust manager.

bq. I am fine with either OSCP or CRL verification as long as the admin is aware of how this affects the latency of session setup and reliability of the Quorum since they are all perhaps talking to one entity(hopefully not) for this to work.
I agree. We need to document this drawbacks clearly.

bq. Also I noticed the ZOOKEEPER-2184 could be addressed by some of my plumbing changes that pass the configured hostname around along with the resolved ip address. 
There is an active PR for this so I don't think we need to address it in this patch.

bq. It is best to combine the PRs into one so we can collaborate and increase the velocity.
I agree.

bq.  I would like to suggest that we use X509ExtendedTrustManager
If the concerns I listed above with hostname verification can be addressed I would be open to this.

bq. I would like to keep the BC helper code
What do you mean by bc helper code?

bq.  I lean towards just changing Socket() calls to something else but not adding any more code to Leader.java, Follower.java, Learner.java etc.
Sounds like a good idea. Once we get the implementation details flushed out there will be plenty of refactoring to clean this stuff up.

Thanks,
Abe


> 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)