zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Powell Molleti (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-236) SSL Support for Atomic Broadcast protocol
Date Thu, 16 Mar 2017 05:38:42 GMT

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

Powell Molleti commented on ZOOKEEPER-236:

Hi Abe,

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. Or you could argue
that we only need hostname verification for the "client", but I would rather have it both
ways. Please let me know if I am missing something.

If multiple servers have certs with the same subjectAltName entry of type dNSName and that
is indeed is how the CA signed them then it should be ok from TLS perspective, since we trust
the CA, we trust any server signed by the CA and we match the hostname(i.e we trust DNS lookup
or we trust the config provided). We do not have to verify the specific host since it is sufficient
to verify that it is one of the valid hosts, this is secure.

Take a case where if someone can subvert the CA get signed by it for the same domain and subvert
DNS then they might as well try few sids starting from zero before ZK lets the server connect.

Hostname verification does not apply to self-signed certs. I am quite skeptical about the
need for hostname verification in private CA (enterprise setting) too. We should probably
have it off by default and let the admin turn it on.

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

BC is bouncy castle.

Also wanted to ask you if we could make the all sockets BufferedSocket by default rather then
making that conditional on port unification configuration.

I need to restore backward compatibility to X509Util, I removed the public statics that were
marked deprecated, probably cannot do that just yet?.


> 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

View raw message