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 Wed, 25 Sep 2013 21:33:04 GMT

    [ 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

Mime
View raw message