[
https://issues.apache.org/jira/browse/CASSANDRA-13314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961510#comment-15961510
]
Jason Brown commented on CASSANDRA-13314:
-----------------------------------------
One tricky thing to watch out for is the overloaded use of the term "protocol"
(this keeps tripping me up). On one hand "protocol" is the string that is
passedd to {{SSLContext#getInstance}}; I believe the only common vaues are
"TLS" and "LDAP". The other use of protocol is what TLS versions should be
used; this value is an argument to {{SSLEngine#setEnabledProtocols}} or
{{SSLSocket#setEnabledProtocols}}. Values for this "protocol" look like:
"TLSv1", "TLSv1.1", "TLSv1.2", and we used to have it hardcoded in
{SSLFactory#ACCEPTED_PROTCOLS}}. I think the former case can be removed from
the yaml (it's {{protocol}} entry under both {{server_encryption_options}} and
{{client_encryption_options}}). I'll leave discussion of the latter case to
CASSANDRA-13325.
bq. I wonder if we should rely on the netty defaults (for cipher suites)
instead for both JDK and OpenSSL
I agree with this, and will make the change in CASSNADRA-8457. ftr, netty has a
({{CihperSuiteConverter}}|https://github.com/netty/netty/blob/4.1/handler/src/main/java/io/netty/handler/ssl/CipherSuiteConverter.java)
for munging the JDK cipher suite names OpenSsl will be happy with, so there's
no problem with using the "names" of the JDK cipher suites as input to openssl
(at that point, it's up to the specific openssl implemenation to actually
support the cihper suite).
I'm wondering if we can eliminate both {{algorithm}} and {{protocol}} (see
above). It's hard to imagine that ever being different than the JDK defaults
("SunX509" and "TLS", respectively). Only unless you've implemented or use a
custom JSSE provider where those values *might* be different (potentially), and
we can always add support for those properties back in if necessary.
wrt {{store_type}} I'm cool with using the jdk default, but what happens if the
default changes? Fortunately, according to Java 9's {JEP
229|http://openjdk.java.net/jeps/229):
{quote}
Existing applications must not be disrupted ... This requirement is achieved by
introducing a keystore detection mechanism that understands both the JKS and
PKCS12 formats. A keystore's format is examined before it is loaded to
determine its type and then the appropriate keystore implementation is used to
access it. The mechanism is enabled by default but can be disabled if required.
{quote}
Thus, I think we are fine on that front. My only wonder is if we need to allow
the keystore and truststore to have their own individual {{store_type}}
property, but I'm not sure it's warrented/is config overkill. wdyt?
Once 4.0 is ready we'll have to do some clean up maintenance on the docs, but
that's to be expected.
bq. can you check if you can enable endpoint verification in NettyFactory
lol, when you read this code, yeah, hostname verification was broken. i fixed
it a few days before (finally) reading this ticket ;)
> 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)
