Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 28 Aug 2015 15:21:45 +0000 (UTC)
From: "Stefan Podkowinski (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12837388.1434110750000.194843.1440775305910@Atlassian.JIRA>
In-Reply-To: <JIRA.12837388.1434110750000@Atlassian.JIRA>
References: <JIRA.12837388.1434110750000@Atlassian.JIRA>
 <JIRA.12837388.1434110750490@arcas>
Subject: [jira] [Updated] (CASSANDRA-9590) Support for both encrypted and
 unencrypted native transport connections
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-9590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Podkowinski updated CASSANDRA-9590:
------------------------------------------
    Description: 
Enabling encryption for native transport currently turns SSL exclusively on or off for the opened socket. Migrating from plain to encrypted requires to migrate all native clients as well and redeploy all of them at the same time after starting the SSL enabled Cassandra nodes. 

This patch would allow to start Cassandra with both an unencrypted and ssl enabled native port. Clients can connect to either, based whether they support ssl or not.

This has been implemented by introducing a new {{native_transport_port_ssl}} config option. 
There would be three scenarios:
* client encryption disabled, {{native_transport_port}} unencrypted, {{native_transport_port_ssl}} not used
* client encryption enabled, {{native_transport_port_ssl}} not set, {{native_transport_port}} encrypted
* client encryption enabled, {{native_transport_port_ssl}} set, {{native_transport_port}} unencrypted, {{native_transport_port_ssl}} encrypted

This approach would keep configuration behavior fully backwards compatible.

Patch proposal: [Branch|https://github.com/spodkowinski/cassandra/tree/cassandra-9590], [Diff trunk|https://github.com/apache/cassandra/compare/trunk...spodkowinski:cassandra-9590], [Patch against trunk|https://github.com/apache/cassandra/compare/trunk...spodkowinski:cassandra-9590.patch]

DTest: [Branch|https://github.com/spodkowinski/cassandra-dtest/tree/cassandra-9590], [Diff trunk|https://github.com/riptano/cassandra-dtest/compare/master...spodkowinski:cassandra-9590]


  was:
Enabling encryption for native transport currently turns SSL exclusively on or off for the opened socket. Migrating from plain to encrypted requires to migrate all native clients as well and redeploy all of them at the same time after starting the SSL enabled Cassandra nodes. 

This patch would allow to start Cassandra with both an unencrypted and ssl enabled native port. Clients can connect to either, based whether they support ssl or not.

This has been implemented by introducing a new {{native_transport_port_ssl}} config option. 
There would be three scenarios:
* client encryption disabled: native_transport_port unencrypted, port_ssl not used
* client encryption enabled, port_ssl not set: encrypted native_transport_port
* client encryption enabled and port_ssl set: native_transport_port unencrypted, port_ssl encrypted

This approach would keep configuration behavior fully backwards compatible.

Patch proposal (tests will be added later in case people will speak out in favor for the patch):
[Diff trunk|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/optionalnativessl], 
[Patch against trunk|https://github.com/apache/cassandra/compare/trunk...spodkowinski:feat/optionalnativessl.patch]


> Support for both encrypted and unencrypted native transport connections
> -----------------------------------------------------------------------
>
>                 Key: CASSANDRA-9590
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9590
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Stefan Podkowinski
>             Fix For: 2.1.x
>
>
> Enabling encryption for native transport currently turns SSL exclusively on or off for the opened socket. Migrating from plain to encrypted requires to migrate all native clients as well and redeploy all of them at the same time after starting the SSL enabled Cassandra nodes. 
> This patch would allow to start Cassandra with both an unencrypted and ssl enabled native port. Clients can connect to either, based whether they support ssl or not.
> This has been implemented by introducing a new {{native_transport_port_ssl}} config option. 
> There would be three scenarios:
> * client encryption disabled, {{native_transport_port}} unencrypted, {{native_transport_port_ssl}} not used
> * client encryption enabled, {{native_transport_port_ssl}} not set, {{native_transport_port}} encrypted
> * client encryption enabled, {{native_transport_port_ssl}} set, {{native_transport_port}} unencrypted, {{native_transport_port_ssl}} encrypted
> This approach would keep configuration behavior fully backwards compatible.
> Patch proposal: [Branch|https://github.com/spodkowinski/cassandra/tree/cassandra-9590], [Diff trunk|https://github.com/apache/cassandra/compare/trunk...spodkowinski:cassandra-9590], [Patch against trunk|https://github.com/apache/cassandra/compare/trunk...spodkowinski:cassandra-9590.patch]
> DTest: [Branch|https://github.com/spodkowinski/cassandra-dtest/tree/cassandra-9590], [Diff trunk|https://github.com/riptano/cassandra-dtest/compare/master...spodkowinski:cassandra-9590]


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)