[
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)
