You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Joey Lynch (Jira)" <ji...@apache.org> on 2020/03/17 19:04:00 UTC

[jira] [Comment Edited] (CASSANDRA-15262) server_encryption_options is not backwards compatible with 3.11

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

Joey Lynch edited comment on CASSANDRA-15262 at 3/17/20, 7:03 PM:
------------------------------------------------------------------

Hi, yes I just uploaded my mostly complete patch for this:
 * [branch|https://github.com/jolynch/cassandra/tree/CASSANDRA-15262]
 * [46347bbeab0a53f9a546346dac685294751e4119|https://github.com/apache/cassandra/commit/46347bbeab0a53f9a546346dac685294751e4119]
 * [tests|https://circleci.com/workflow-run/4a67351b-4fb6-4491-9b60-017597be14d8]

Unfortunately the server enabled flag got put a bunch of places in trunk (tools, virtual tables, unit tests, configuration startup checks) so I think the only safe way to remove it from server options is to make the member private and use a proper getter that the subclass overrides. The alternative is to make the member mutable but I'd prefer not to do that).

I still need to:
 * Generate local keystores/truststores and verify that various configurations of nodes can start using CCM with multiple datacenters and various values of internode_encryption
 * Update the CHANGES to indicate that the optional default is changing in client_envryption_options (this could be a security vulnerability for existing users)
 * Verify dtests work properly with the changes


was (Author: jolynch):
Hi, yes I just uploaded my mostly complete patch for this:
 * [branch|https://github.com/jolynch/cassandra/tree/CASSANDRA-15262]
 * [46347bbeab0a53f9a546346dac685294751e4119|https://github.com/apache/cassandra/commit/46347bbeab0a53f9a546346dac685294751e4119]
 * [tests|https://circleci.com/workflow-run/4a67351b-4fb6-4491-9b60-017597be14d8]

Unfortunately the server enabled flag got put a bunch of places in trunk (tools, virtual tables, unit tests, configuration startup checks) so I think the only safe way to remove it from server options is to make the member private and use a proper getter that the subclass overrides. The alternative is to make the member mutable but I'd prefer not to do that).

I still need to:
 * Generate local keystores/truststores and verify that two nodes can start using CCM
 * Update the CHANGES to indicate that the optional default is changing in client_envryption_options (this could be a security vulnerability for existing users)
 * Verify dtests work properly with the changes

> server_encryption_options is not backwards compatible with 3.11
> ---------------------------------------------------------------
>
>                 Key: CASSANDRA-15262
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15262
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Local/Config
>            Reporter: Joey Lynch
>            Assignee: Joey Lynch
>            Priority: Normal
>             Fix For: 4.0, 4.0-alpha
>
>
> The current `server_encryption_options` configuration options are as follows:
> {noformat}
> server_encryption_options:
>     # set to true for allowing secure incoming connections
>     enabled: false
>     # If enabled and optional are both set to true, encrypted and unencrypted connections are handled on the storage_port
>     optional: false
>     # if enabled, will open up an encrypted listening socket on ssl_storage_port. Should be used
>     # during upgrade to 4.0; otherwise, set to false.
>     enable_legacy_ssl_storage_port: false
>     # on outbound connections, determine which type of peers to securely connect to. 'enabled' must be set to true.
>     internode_encryption: none
>     keystore: conf/.keystore
>     keystore_password: cassandra
>     truststore: conf/.truststore
>     truststore_password: cassandra
>     # More advanced defaults below:
>     # protocol: TLS
>     # store_type: JKS
>     # cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
>     # require_client_auth: false
>     # require_endpoint_verification: false
> {noformat}
> A couple of issues here:
> 1. optional defaults to false, which will break existing TLS configurations for (from what I can tell) no particularly good reason
> 2. The provided protocol and cipher suites are not good ideas (in particular encouraging anyone to use CBC ciphers is a bad plan
> I propose that before the 4.0 cut we fixup server_encryption_options and even client_encryption_options :
> # Change the default {{optional}} setting to true. As the new Netty code intelligently decides to open a TLS connection or not this is the more sensible default (saves operators a step while transitioning to TLS as well)
> # Update the defaults to what netty actually defaults to



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org