[ https://issues.apache.org/jira/browse/CASSANDRA-10404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16191008#comment-16191008 ]
Jason Brown commented on CASSANDRA-10404: ----------------------------------------- Missed this update, for some stupid reason bq. 1) Assuming we have a 3.x cluster already running with ssl enabled and now start to bump the first node to 4.0. If we connect to storage_port by default in 4.0, won't the upgraded node fail to start with a "Unable to gossip with any seeds" error? As I explained in the previous comment, this is the trickiest part of this patch. The upgraded node, after it bounces, must have at least one 3.0 node connect to it, and have a gossip session, for the upgraded node to a) learn about the version of the node that contacted via the handshake protocol, and b) learn about the version of other nodes in the the cluster via that round of gossip. Having that first round of gossip is critical for getting the versions of peers, which we check on each {{OutboundMessagingService#tryConnect}} attempt. This does not guarantee that the upgraded node will learn about the 3.0 status of nodes in it's seed list before the shadow round fails, although I think the possiblity of shadow round failure is rather low as un-upgraded nodes will be trying to connect to the upgraded node (as it will be seen as DOWN by the peers, and they will be attempting to connect via gossip). The possibility of shadow round failure is non-zero, however, and I'm open to ideas on the cluster upgrade scenario. bq. 2) Do we want to add an option to disable the ssl_storage_port? E.g. by setting it to the same value as storage_port? Maybe we can add another property under the {{server_encryption_options}}, something like {{enable_legacy_ssl_storage_port}}. That would also clean up {{MessagingService#listen}} a little bit. wdyt? bq. 3) doc/source/operating/security.rst: needs to be updated Yup, I'll be happy do so when we have solid idea of where the code is going. bq. 4) cassandra.yaml: comments for storage_port and ssl_storage_port not accurate anymore, as both can use encryption now. We also should clearly describe the port as legacy port only used during upgrades. There should be a link to security.rst for further details. Ahh, good catch. Let's figure out the code and yaml props first, then I'll come back to properly wording the yaml comments. bq. 5) Some of the native transport and internode netty code has become redundant, e.g. Server.OptionalSecureInitializer and the new OptionalSslHandler. It's probably not in scope of this ticket, but should maybe addressed in another ticket at some point. I totally agree about the redundancy, and I would like to make that a follow up ticket. bq. 6) Use of server_encryption in NettyFactory.OutboundInitializer could use some comments, especially on why we don't have to check all remaining options such as internode_encryption (already checked in MessagingService) I've added a comment to {{NettyFactory.OutboundInitializeer#initChannel()}} about where the TLS determination happens, but admittedly I'm not a fan of burying the pointer to that so far down the code path. Not sure what's a better solution ... > Node to Node encryption transitional mode > ----------------------------------------- > > Key: CASSANDRA-10404 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10404 > Project: Cassandra > Issue Type: New Feature > Reporter: Tom Lewis > Assignee: Jason Brown > Fix For: 4.x > > > Create a transitional mode for encryption that allows encrypted and > unencrypted traffic node-to-node during a change over to encryption from > unencrypted. This alleviates downtime during the switch. > This is similar to CASSANDRA-10559 which is intended for client-to-node -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org