cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Per Otterström (JIRA) <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10404) Node to Node encryption transitional mode
Date Tue, 17 Oct 2017 08:11:00 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16207152#comment-16207152
] 

Per Otterström commented on CASSANDRA-10404:
--------------------------------------------

I did some manual verification on these patch sets using mixed major versions with SSL enabled.
With good results.

A small nit on the patch. I would prefer to keep {{OutboundConnectionIdentifier.withUpdatedRemotePort()}}
next to {{withNewConnectionAddress()}}. Can we make the names of these methods more consistent?

If {{optional: true}}, then the legacy ssl_storage_port will also accept non-secured connections
which is probably not expected behavior. We could pass in a force flag to the {{InboundInitializer}}
when it is instantiated.

The patch set is touching a lot of files because {{ClientEncryptionOptions}} is removed. Please
consider changes in CASSANDRA-13404. If it is going in we will re-introduce {{ClientEncryptionOptions}}.

bq. 2) Having that flag next to the new enabled flag should work. The yaml file needs attention
during upgrade anyways. So if you upgrade from 3.0 with ssl enabled, you'd have to set both
"enabled: true" and "enable_legacy_ssl_storage_port: true" in your config.

+1

bq. 3) Hostname verification: I've pushed a commit here that will honor the require_endpoint_verification
flag for incoming connections.

+1

bq. 4) If we want to avoid potential attacks with invalid or stolen certificates, we should
also enable require_client_auth by default. This should not cause any issues, as the truststores
need to be managed for outgoing connections anyways. So why not validate incoming connections
as well?

I think it is rather common that clusters are using certificates that don't validate well.
So changing the default value could generate some unpleasant surprises.

I wasn't able to do upgrade from 3.0 to trunk with SSL enabled. It would result in exceptions
with {{SSLv2Hello is disabled}}. But I don't think it is related to these changes. Will investigate
a bit further and create a separate ticket for it.

> 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message