Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Wed, 25 Sep 2013 21:02:03 +0000 (UTC)
From: "Michael Allen (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12629984.1359576401192.19788.1380142923365@arcas>
In-Reply-To: <JIRA.12629984.1359576401192@arcas>
References: <JIRA.12629984.1359576401192@arcas>
Subject: [jira] [Commented] (ACCUMULO-1009) Support encryption over the wire
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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