[
https://issues.apache.org/jira/browse/CASSANDRA-10508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-10508:
-------------------------------------------
Description:
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.- (fixed in CASSANDRA-11164)
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.
was:
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.
> Remove hard-coded SSL cipher suites and protocols
> -------------------------------------------------
>
> Key: CASSANDRA-10508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10508
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Stefan Podkowinski
> Assignee: Stefan Podkowinski
> Labels: docs-impacting, 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.- (fixed in CASSANDRA-11164)
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
