[
https://issues.apache.org/jira/browse/ACCUMULO-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13765850#comment-13765850
]
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 instance.javax.net.ssl.* or
general.javax.net.ssl.* 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 (eg. javax.net.ssl.keyStoreProvider).
{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.{quote}
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}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 "monitor.javax.net.ssl.keyStore" is "javax.net.ssl.keyStore" 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: 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
