[
https://issues.apache.org/jira/browse/ACCUMULO-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13775907#comment-13775907
]
Christopher Tubbs commented on ACCUMULO-1009:
---------------------------------------------
{quote}your own recent major points{quote}
Points that haven't been addressed fully yet.
{quote}Really?{quote}
Yes. If everybody can behave as the CA, then this is no more secure than having
every node generate its own self-signed certificate, or reusing the same
certificate for every node. This mechanism adds complexity, but not more
security. Further, it masquerades as extra security, by implying a particular
trust model that is not actually followed. Additionally, by making the
encrypted private key widely available, it reduces the security of the CA's
private key to a much more attainable instance secret that's available on every
box in the cluster.
In any case, that was just a passing comment; if you actually implement it,
I'll review the patch directly.
{quote}As it is, if you have the instance secret, you can do whatever you want
with the accumulo cluster.{quote}
That's true without SSL, but it doesn't have to be true with SSL. Especially if
we get ZK using SSL (or at least authenticating with certificates), we can get
rid of the instance.secret entirely. I'd rather not add an additional mechanism
to rely on it if we don't need to.
{quote}Why is wrapping keytool or openssl better than wrapping
bouncycastle?{quote}
Every version of Java that can run Accumulo comes with keytool. openssl is a
dependency of yum, apt, ssh, and lsb, and we don't have to package them or
maintain custom code to leverage them (just documentation). keytool can use an
installed bouncycastle, if it is available on the runtime system. keytool and
openssl are familiar tools to system administrators and security-conscious
users. They have better documentation and external support, and known security
risks. They have a demonstrable level of trust, and an explicit scope, and are
the de facto tools for users of more popular SSL-enabled services.
{quote}BC can be pulled in as a maven dependency{quote}
So can keytool-maven-plugin, which can use bouncycastle as a test dependency.
We don't need to package it as an additional runtime dependency if we just want
it for testing.
> 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
