[
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
