[
https://issues.apache.org/jira/browse/ZOOKEEPER-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900447#comment-15900447
]
Michael Han commented on ZOOKEEPER-236:
---------------------------------------
Thanks Abe for driving this. I have some comments for your questions in pull
request.
bq. I am using the same configuration that points to the truststore/keystore
used for server <-> client ssl. Do they need to be separate?
Separate configuration option provides better flexibility and is also
consistent with SASL / Kerberos configurations for client-server and
server-server. For example we have separate server login context for server
credential in client-server and server-server cases (ZOOKEEPER-1045), the
keytab might be the same but the configuration options are separate.
bq. Is port unification the correct approach for rolling upgrades?
I think it might be helpful to do some scoping and decide if we want to support
rolling upgrade - or supporting rolling upgrade in first release of this patch.
When it comes to security usually customers are OK to do a cold restart. Not
saying that we should not support rolling upgrade someday but you might also
want consider the amount of work involved to support it (implementation, how to
properly testing, etc.) and it might be easier if we do this in phases - unless
it is trivial to implement and test rolling upgrade (I haven't looked this in
much details.) or folks feel it is absolutely required to get rolling upgrade
capability before shipping this feature.
bq. server logic with netty was necessary given how easy ssl was to implement
with standard java `SSLSocket`s. Any arguments to the contrary?
Today we don't use Netty for server-server chat so it seems no immediate needs
to rely on Netty for this work. Though, issues like ZOOKEEPER-900 and
ZOOKEEPER-901 might push towards the direction of using Netty so the FLE and
server chats are none blocking, plus we have TLS on Netty for client-server
secured communication, so for consistency we could choose to implement TLS on
Netty for server-server as well. I am interesting to hear what others think
about this.
> 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)
