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 Wed, 15 Mar 2017 16:27:41 GMT

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

Powell Molleti commented on ZOOKEEPER-236:
------------------------------------------

Hi Abe,

Few comments about the changes:

One way to go is to minimize changes to Leader.java, Follower.java, Learner.java etc. This
will help anyone who wants to abstract away sockets from that code. Let me know what you think.

Regarding host verification one other way to go is to follow this:
[X509ExtendedTrustManager|http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#X509ExtendedTrustManager]
mentions about where to plugin host verification , it specifically quotes:
{noformat} Besides TLS 1.2 support, the X509ExtendedTrustManager class also support algorithm
constraints and SSL layer hostname verification. For JSSE providers and trust manager implementations,
the X509ExtendedTrustManager class is highly recommended rather than the legacy X509TrustManager
interface. {noformat}

It is possible to argue that thought TLS does not perform host verification 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. 

It is possible to minimize risk by extending X509ExtendedTrustManager and calling default
TrustManager's API first and then performing extra checks. Something like a composite X509TrustManager.
This will also help others add to the list of checks in one place and all of this could be
conditional based on options passed.

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.

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. Hence avoiding reverse
DNS lookups when hostname is provided at config time etc. 

It is best to combine the PRs into one so we can collaborate and increase the velocity. We
should agree on few things, I would like to suggest that we use X509ExtendedTrustManager and
also minimize the amount of changes and maintain compatibility for client - server, I would
like to keep the BC helper code in unit tests and the unit tests. I lean towards just changing
Socket() calls to something else but not adding any more code to Leader.java, Follower.java,
Learner.java etc.

Let me know what you prefer.
thanks
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)

Mime
View raw message