Joseph Lynch created CASSANDRA-15146: ----------------------------------------
Summary: Transitional TLS configuration options are overly complex Key: CASSANDRA-15146 URL: https://issues.apache.org/jira/browse/CASSANDRA-15146 Project: Cassandra Issue Type: Bug Reporter: Joseph Lynch Assignee: Joseph Lynch It appears as part of the port from transitional client TLS to transitional server TLS in CASSANDRA-10404 (the ability to switch a cluster to using {{internode_encryption}} without listening on two ports and without downtime) we carried the {{enabled}} setting over from the client implementation. I believe that the {{enabled}} option is redundant to {{internode_encryption}} and {{optional}} and it should therefore be removed prior to the 4.0 release where we will have to start respecting that interface. Current trunk yaml: {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 {noformat} I propose we eliminate {{enabled}} and just use {{optional}} and {{internode_encryption}} to determine the listener setup. I also propose we change the default of {{optional}} to true. We could also re-name {{optional}} since it's a new option but I think it's good to stay consistent with the client and use {{optional}}. ||optional||internode_encryption||description|| |true|none|(default) No encryption is used but if a server reaches out with it we'll use it| |false|dc|Encryption is required for inter-dc communication, but not intra-dc| |false|all|Encryption is required for all communication| |false|none|We listen for either encrypted or unencrypted| |true|dc|Encryption is used for inter-dc communication but is not required| |true|all|Encryption is used for all communication but is not required| >From these states it is clear when we should be accepting TLS connecitons (all >except for the first) as well as when we must enforce it. To transition without downtime from an un-encrypted cluster to an encrypted cluster the user would do the following: 1. After adding valid truststores, change {{internode_encryption}} to the desired level of encryption (recommended {{all}}) and restart Cassandra 2. Change {{optional=false}} and restart Cassandra If {{optional}} defaulted to {{false}} as it does right now we'd need a third restart to first change {{optional}} to {{true}}, which given my understanding of the OptionalSslHandler isn't really relevant. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org