[
https://issues.apache.org/jira/browse/CASSANDRA-10508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15151829#comment-15151829
]
Robert Stupp commented on CASSANDRA-10508:
------------------------------------------
Took a brief look at the diff and the changes look good so far. One question:
Would it make sense to actually add a new config "allowed_protocols" instead of
sticking with the system property (in a separate ticket)? It's more about "keep
things in cassandra.yaml" and being able to differ between server and client
connections. Frankly, I don't think it's really necessary to separate by client
and server for the protocols . I'm just asking.
> Remove hard-coded SSL cipher suites and protocols
> -------------------------------------------------
>
> Key: CASSANDRA-10508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10508
> Project: Cassandra
> Issue Type: Bug
> Reporter: Stefan Podkowinski
> Assignee: Stefan Podkowinski
> Labels: lhf
> Fix For: 3.x
>
>
> Currently each SSL connections will be initialized using a hard-coded list of
> protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We
> now require Java 8 which comes with solid defaults for these kind of SSL
> settings and I'm wondering if the current behavior shouldn't be re-evaluated.
> In my impression the way cipher suites are currently whitelisted is
> problematic, as this will prevent the JVM from using more recent and more
> secure suites that haven't been added to the hard-coded list. JVM updates may
> also cause issues in case the limited number of ciphers cannot be used, e.g.
> see CASSANDRA-6613.
> Looking at the source I've also stumbled upon a bug in the
> {{filterCipherSuites()}} method that would return the filtered list of
> ciphers in undetermined order where the result is passed to
> {{setEnabledCipherSuites()}}. However, the list of ciphers will reflect the
> order of preference
> ([source|https://bugs.openjdk.java.net/browse/JDK-8087311]) and therefore you
> may end up with weaker algorithms on the top. Currently it's not that
> critical, as we only whitelist a couple of ciphers anyway. But it adds to the
> question if it still really makes sense to work with the cipher list at all
> in the Cassandra code base.
> Another way to effect used ciphers is by changing the security properties.
> This is a more versatile way to work with cipher lists instead of relying on
> hard-coded values, see
> [here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms]
> for details.
> The same applies to the protocols. Introduced in CASSANDRA-8265 to prevent
> SSLv3 attacks, this is not necessary anymore as SSLv3 is now blacklisted
> anyway and will stop using safer protocol sets on new JVM releases or user
> request. Again, we should stick with the JVM defaults. Using the
> {{jdk.tls.client.protocols}} systems property will always allow to restrict
> the set of protocols in case another emergency fix is needed.
> You can find a patch with where I ripped out the mentioned options here:
> [Diff
> trunk|https://github.com/apache/cassandra/compare/trunk...spodkowinski:fix/ssloptions]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
