You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Benedict (JIRA)" <ji...@apache.org> on 2019/05/31 12:16:00 UTC
[jira] [Commented] (CASSANDRA-15146) Transitional TLS server
configuration options are overly complex
[ https://issues.apache.org/jira/browse/CASSANDRA-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852956#comment-16852956 ]
Benedict commented on CASSANDRA-15146:
--------------------------------------
Perhaps we should generally massage this a bit.
Is {{server_encryption_options}} very clear, for instance? {{internode_encryption}} would be clearer to me. With perhaps a {{protect}} field accepting {{none}}, {{inter_dc}}, {{all}}?
Should we consider getting rid of the {{_options}} for both (while still supporting {{_options}} for client indefinitely)? The word is redundant, given the context.
> Transitional TLS server configuration options are overly complex
> ----------------------------------------------------------------
>
> Key: CASSANDRA-15146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15146
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
> Reporter: Joseph Lynch
> Assignee: Joseph Lynch
> Priority: Normal
>
> 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 only listen for unencrypted connections|
> |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 connections (all except for false and none) 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 to enforce #1
> 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org