[
https://issues.apache.org/jira/browse/ACCUMULO-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13778110#comment-13778110
]
Christopher Tubbs commented on ACCUMULO-1009:
---------------------------------------------
A better mechanism would be to leave the CA on one box (the master?) and have
tservers generate certs and submit the public key to the master for signing.
This can be automated to the same degree as the previous proposed
implementation, and is far more secure. There's no reason to automate an bad
method of key distribution, when a better mechanism offers the same level of
convenience, and better security, with the same user experience (they still
have to execute "init-ssl" on each box). This argument is not an argument
against the target goal of convenience... it was simply an attempt at pointing
out flaws in one possible implementation of that convenience feature.
{quote}To break the system you describe, you would have to break into a node
and find the client certificate. Having different client certificates has a
better recovery strategy (invalidate that one certificate), but it isn't any
better when it comes to an attacker attempting to undermine the system.{quote}
To me, that seems like a huge change to the "security equation".
{quote}I'm all for getting rid of secrets we do not need{quote}
Getting SSL authentication to ZK is a harder task, and I see it as separate
from this ticket (a sub-ticket, or related ticket, perhaps). We won't be able
to get rid of the instance.secret until that's done (at least). I just worry
that the previously proposed mechanism would create an additional (unnecessary)
dependency on it.
However, further discussions about the particular implementation of a
certificate provisioning solution seems futile, though, until we can address
whether provisioning should be included in the first place. If it is included,
then we need to address whether it is sensible to do it with an additional
dependency and custom code (rather than leverage the available tools already on
the system and specifically designed for that purpose).
> Support encryption over the wire
> --------------------------------
>
> Key: ACCUMULO-1009
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1009
> Project: Accumulo
> Issue Type: New Feature
> Reporter: Keith Turner
> Assignee: Michael Berman
> Fix For: 1.6.0
>
> Attachments: ACCUMULO-1009_thriftSsl.patch
>
>
> Need to support encryption between ACCUMULO clients and servers. Also need
> to encrypt communications between server and servers.
> Basically need to make it possible for users to enable SSL+thrift.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
