[ 
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)

Reply via email to