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