[
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
