[
https://issues.apache.org/jira/browse/CASSANDRA-10404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969734#comment-15969734
]
Jason Brown commented on CASSANDRA-10404:
-----------------------------------------
Linked is a first pass at implementing this behavior, based on the current
(in-flight) CASSANDRA-8457. I'm posting this now to get some feedback on the
idea/implementation. Hence, I haven't added tests (or dtests) yet. As
[[email protected]] noted, adding in this functionality is rather trivial with
CASSADNRA-8457 in place.
The essence of this patch is to add two new configuration props to the
{{ServerEncryptionOptions}}, {{optional}} and {{enabled}}. They will be
functional equivalent to what we already have for {{ClientEncryptionOptions}},
and thus allow us to do unencrypted and encrypted communication from the same
listening internode messaging socket. Most of the patch is refactoring of the
{{EncryptionOptions}} and {{OptionalSslHandler}} classes, and the interesting
functional bits are in the yaml and MessagingService.
bq. But how would we handle such transition when it comes to used storage_ports?
I'm imagining that for 4.0 we still need both {{storage_port}} and
{{ssl_storage_port}} in place to support cluster upgrades. Upgraded nodes will
be smart enough to connect on the {{storage_port}} (which will be intelligent
to figure out if the connection is TLS or not). Unupgraded nodes can still
connect on the legacy port (as we'll need to listen on it, as well). At 5.0,
then, we can retire the {{ssl_storage_port}} and simply have one port and
config option for internode messaging with TLS.
Also, once this ticket is in place, it will make [~aweisberg]'s patch for
CASSANDRA-7544 simpler as he won't (hopefully!) need to worry about passing
around the {{ssl_storge_port}} as all 4.0 nodes who can listen to the new
CASSANDRA-7544 data being passed around will also be smart enough to connect to
the {{storage_port}} for TLS behavior. Hence, another reason I'm eager to get
this in.
> 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
>
> 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.3.15#6346)