[jira] [Commented] (CASSANDRA-13314) Config file based SSL settings

["Jason Brown (JIRA)" <ji...@apache.org>]

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