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:
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.
|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.