cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13314) Config file based SSL settings
Date Fri, 10 Mar 2017 22:59:04 GMT

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

Jason Brown commented on CASSANDRA-13314:
-----------------------------------------

See my comments on CASSANDRA-13259, but TL;DR netty doesn't use the {{javax.net.ssl.*}} properties.

> 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