accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1009) Support encryption over the wire
Date Thu, 12 Sep 2013 20:07:52 GMT


Christopher Tubbs commented on ACCUMULO-1009:

[~mberman] wrote:
{quote}I'm not rewriting any custom socket code{quote}

That's good at least, but...

{quote}There's no way the JSSE properties can be respected automatically{quote}

is simply not true. See TSSLTransportFactory.getServerSocket(int port) or the two param one
(int, int)'s javadoc.

Whether you use this method or the one that explicitly passes these properties, I don't care...
so long as it falls back on the JSSE properties, the configuration looks similar to JSSE property
names, and it supports all the features that the JSSE properties would if they were set as
system properties.

{quote}This is not a client-side setting{quote}

The issue is applicable to both client-side configuration and server-side configuration. My
previously expressed opinions were primarily for client-side configuration. For server-side,
I've been thinking about better scoped configuration anyway (separate config files... not
xml, and separate enums, for separate services). That would resolve some of these questions
about where to put configuration and would address the monitor's limited ssl configuration
as well. In the meantime, I think something like* or*
might be a decent compromise for server configuration.

{quote}the tservers themselves need to know where to find the keyStore.{quote}

Recall that part of my criticism of a keyStore-only based configuration was based on the idea
that there are other JSSE properties allow you to configure an alternate provider as well

{quote}This means that probably you want the monitor to have a cert cut from a "real" CA,
but enforcing that requirement for every tserver will be unwieldy and not necessary for most

How is this unwieldy? I concede that monitor may have different certs than tservers, but I
don't agree that having a "real" CA for every tserver will be unwieldy or unnecessary. Having
a CA that is trusted sign the certs used by the tservers is essential for clients communicating
with the SSL-enabled instance... otherwise, they'll have to have a trustStore that includes
the cert of every tserver... and *that* is unwieldy. Unless you were planning on making clients
trust anything that the tserver throws at them... which would undermine the security of the

{quote}Is there any particular reason that it's ok for the monitor to have custom SSL properties,
but not the RPC connections?{quote}

No. See my suggestion above for the scoping of properties in separate properties files, and
the compromise for prefixing them with a particular scope. The main point is I want users
to understand at a glance that something like "" is ""
scoped to "monitor". This gets murkier, if the property names are "monitor.ssl.keyStore",
but we're stuck with that for now. The main point I want to make for the RPC is that I want
to ensure we're moving forward towards a more intuitive and flexible configuration standards.
It is not necessarily a blocker for the feature.
> Support encryption over the wire
> --------------------------------
>                 Key: ACCUMULO-1009
>                 URL:
>             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:

View raw message