accumulo-notifications mailing list archives

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

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

Michael Berman commented on ACCUMULO-1009:
------------------------------------------

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

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

My point was, we at least need to figure out if we want to use a TSSLTransportFactory at all.
 And beyond that, the stack is still quite different since the THsHaServer doesn't support
SSL.  So I'm still confident "we will end up examining and branching based on the properties
no matter how we do it" is true.

{quote}
I think something like instance.javax.net.ssl.* or general.javax.net.ssl.* might be a decent
compromise for server configuration.
{quote}

This sounds fine to me.

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

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
(eg. javax.net.ssl.keyStoreProvider).
{quote}

Here I was just using keystore as an example property.  Replace "keyStore" with "keyProvider"
and my point still stands.  But it sounds like this issue is addressed by your other answers
anyway, so no big deal.

{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
deployments.

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
feature.
{quote}

I think you've misunderstood me here.  Absolutely the tservers' certs need to be signed by
a known CA that can be trusted by clients.  I believe there's value in the monitor's https
cert being signed by a public root CA that is likely to be known about by web browsers.  This
is what I meant by a "real" CA, and this is the part that seems unwieldy (and usually unnecessary)
for tserver certs.  It's easier to distribute custom trusted roots to client applications
than to end users' web browsers, and getting certs signed by public trusted roots is expensive,
usually requires manual intervention, and is impossible if you want to do hostname verification
for machines not on the internet.  This is the distinction I was trying to draw between requirements
for monitor vs. thrift certs.  But, since it sounds like you're fine with a service qualifier
before the JSSE-like property key, I believe that addresses my original concern.
                
> 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