cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Podkowinski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13314) Config file based SSL settings
Date Tue, 14 Mar 2017 14:21:41 GMT

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

Stefan Podkowinski commented on CASSANDRA-13314:
------------------------------------------------

I'd also be fine to configure SSL "the netty way" instead of using JVM properties. But there
should be a flexible consistent way for users to do this and as little work as possible on
our side for plumbing and maintaining such settings.

Looking at CASSANDRA-8457 I've noticed that you started to use SslContextBuilder, which would
also allow users to enable [netty-tcnative|http://netty.io/wiki/forked-tomcat-native.html].

There's not really a lot to configure in SslContextBuilder:

KeyManagerFactory
TrustManagerFactory
ClientAuth
Ciphers 
Protocols (starting with [4.1.9|https://github.com/netty/netty/commit/a2304287a170dc14031928d6d2a3374705305839])

I've looked at the 4.0.44 source code to try to figure out how these settings are used and
which of the encryption options would then end up being used where.

*Trust/KeyManagerFactory*: Will be initialized by us using our encryption options, but we
may have to change this for certain netty/openssl combinations, according to the source comment.
I'm not familiar with the requirements for using OpenSSL in netty, but as soon as we provide
a key or trusted certs instead of stores, netty will use hardcoded "JKS" store types and our
store_type setting will be ignored.

*Protocol*: Using netty 4.0.44, SSLContext will be initialized with default hardcoded "TLS"
protocol set. Any protocol configured in cassandra.yaml will be ignored. See link for 4.1.9
above.

*Ciphers*: JdkSslContext uses it's own default ciphers. Same with ReferenceCountedOpenSslContext.
Both with slightly different keys and it looks like the OpenSSL and JDK cipher names doen't
match (TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 vs ECDHE-ECDSA-AES256-GCM-SHA384). Currently
we use the JDK default ciphers if no custom ciphers have been configured in cassandra.yaml.
This will probably not work for OpenSSL and I wonder if we should rely on the netty defaults
instead for both JDK and OpenSSL. 


How about handling settings as follows in respect to CASSANDRA-8457 and 4.0:
*algorithm + store_type*: Used by us for keystore instanciation. Keep cassandra.yaml options,
but use JVM defaults instead of hardcoded defaults. (implement in CASSANDRA-13259)
*ciphers*: Use netty defaults instead of JVM defaults but allow to override from cassandra.yaml
(CASSANDRA-8457)
*protocol*: Same as ciphers, we'd have to allow override through cassandra.yaml to change
the netty default (CASSANDRA-8457, >4.1.9 only)

Afterwards in any later 4.x release, we could go ahead and rethink about how to address ssl
settings for tools. Either by moving settings to jvm.options and source it from the startup
script, by migrating to netty as well or continue to use cassandra.yaml. But at this point
it's probably a bit early to say, so let's take one step after another. 


Btw, on a related side node, can you check if you can [enable endpoint verification|https://github.com/netty/netty/blob/a2304287a170dc14031928d6d2a3374705305839/handler/src/main/java/io/netty/handler/ssl/SslContext.java#L863]
in NettyFactory, as we did starting with c9c9c42263?


> Config file based SSL settings
> ------------------------------
>
>                 Key: CASSANDRA-13314
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13314
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Configuration, Tools
>            Reporter: Stefan Podkowinski
>            Assignee: Stefan Podkowinski
>            Priority: Minor
>             Fix For: 4.x
>
>
> As follow up of CASSANDRA-13259, I'd like to continue discussing how we can make SSL
less awkward to use and further move SSL related code out of our code base. Currently we construct
our own SSLContext in SSLFactory based on EncryptionOptions passed by the MessagingService
or any individual tool where we need to offer SSL support. This leads to a situation where
the user has not only to learn how to enable the correct settings in cassandra.yaml, but these
settings must also be reflected in each tool's own command line options. As argued in CASSANDRA-13259,
these settings could be done as well by setting the appropriate system and security properties
([overview|http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization])
and we should just point the user to the right files to do that (jvm.options and java.security)
and make sure that daemon and all affected tools will source them. 
> Since giving this a quick try on my WIP branch, I've noticed the following issues in
doing so:
> * Keystore passwords will show up in process list (-Djavax.net.ssl.keyStorePassword=..).
We should keep the password setting in cassandra.yaml and clis and do a System.setProperty()
if they have been provided. 
> * It's only possible to configure settings for a single default key-/truststore. Since
we currently allow configuring both ServerEncryptionOptions and ClientEncryptionOptions with
different settings, we'd have to make this a breaking change. I don't really see why you would
want to use different stores for node-to-node and node-to-client, but that wouldn't be possible
anymore. 
> * This would probably only make sense if we really remove the affected CLI options, or
we'll end up with just another way to configure this stuff. This will break existing scripts
and obsolete existing documentation.
> Any opinions?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message