accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-1009) Support encryption over the wire
Date Tue, 24 Sep 2013 01:37:02 GMT

    [ 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

Mime
View raw message