You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jason Brown (JIRA)" <ji...@apache.org> on 2017/04/15 00:44:42 UTC

[jira] [Commented] (CASSANDRA-10404) Node to Node encryption transitional mode

    [ 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 [~spodxx@gmail.com] 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)