accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Allen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-1009) Support encryption over the wire
Date Wed, 25 Sep 2013 21:02:03 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13778077#comment-13778077
] 

Michael Allen commented on ACCUMULO-1009:
-----------------------------------------

bq. 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.

I disagree that providing an easy and automated way to set up SSL provides no more security
and only adds complexity.  Nor will I argue that it provides iron-clad security.  It is a
step along the path towards good security.

It seems like from your previous comments, you think an administrator must make the leap from
no security to all security in one bound.  I think this is a mistake.  Database administrators
are not all familiar with SSL, and how to correctly deploy it.  Deploying it properly is a
mechanical issue, one that can be easily automated.  (By properly I am merely referring to
getting actual SSL connections working, not yet to how the certificate material is secured.)
 Once deployed, network sniffing attacks and man-in-the-middle attacks are thwarted, even
if all Accumulo tserver nodes in the system have access to the issuing CA.  

Securing the issuing CA can just be a matter of having the administrator use a password for
the root certificate's private key that is different than the instance secret.  Every new
node will require that that password be provided, thwarting the ability to have that node
deployed unattended, but ratcheting up the security.  One could also devise a scheme where
the root certificate itself is kept offline until needed, further increasing one's ability
to control access to it.

Having each tserver generate its own self-signed certificate without a root cert is a non-starter
from a deployment perspective.  Getting the entire set of certs out to clients as the trusted
set is too unwieldy to be an effective strategy.  Having the certificates signed by one root
implies that that entity either has access to the instance secret or to the administrators
password used to secure the root certificate.  My judgement is that that is a stronger security
statement than having each server generate their own certificate without a root. 

bq. 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.

I'm not sure this changes the security equation all that much.  To attack the system now you
have to break into a node and find the instance secret.  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.

I'm all for getting rid of secrets we do not need, BTW, don't get me wrong.  Getting ZK to
use SSL is also extremely laudable and a goal to reach for.  I suggest Michael move forward
on getting a patch in shape that automatically generates certificates, and let's hash out
whether or not we think it's good enough from there.

Let me also state one more point: getting Accumulo to the point where the norm is using SSL-based
connections is crucial as a goal, especially when user credentials go in the clear over the
wire otherwise on every Thrift call.  Everything we can do to lower the activation barrier
around setting up SSL makes the system more secure and puts up more barriers to easy attacks.
                
> 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