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

Ekaterina Dimitrova edited comment on CASSANDRA-15262 at 4/30/20, 1:48 AM:
---------------------------------------------------------------------------

[~jolynch], I am not sure whether you had the opportunity to look at the 
failures we talked about last night. 

Update on my end:
Currently the following two D-tests fail:
_     
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl_
-     _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_

- native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl 
fails consistently. Making server_encryption_options:enabled private is not 
working.
I double-checked the changes with the private variable and they look correct. 
This means that there is something more non-trivial? (I am new to this part of 
the codebase, probably you might know something more to be considered than the 
public to private change)
- _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_ fails at the point 
when we restart node1 with encryption being enabled and plaintext port 
shutdown. The inbound connection node2 is refused because of 
_InvalidLegacyProtocolMagic: Read 369295616, Expected -900387334_.
- _client_encryption_options:optional_ should be set to_ False_ in 
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl._

I don't see an issue with the change of optional to default value of True in 
cassandra.yaml but I suggest if we want to setup 
server_encryption_options:enabled to True as a default value, just to leave it 
commented and if the user tries to change it to false - to reject the change 
with a warning. I tried simply to comment server_encryption_options:enabled in 
cassandra.yaml and the tests are passing. 

[~jolynch], considering you mentioned there is already a ticket for improvement 
to land in 4.1 which suggests to split ServerEncryptionOptions class from 
EncryptionOptions class, I would personally leave this patch in the suggested 
way with minimum changes applied to the code as we are in code freeze. WDYT?
 












was (Author: e.dimitrova):
[~jolynch], I am not sure whether you had the opportunity to look at the 
failures we talked about last night. 

Update on my end:
Currently the following two D-tests fail:
_    - native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl
    - TestNodeToNodeSSLEncryption::test_optional_outbound_tls_

- native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl 
fails consistently. Making server_encryption_options:enabled private is not 
working.
I double-checked the changes with the private variable and they look correct. 
This means that there is something more non-trivial? (I am new to this part of 
the codebase, probably you might know something more to be considered than the 
public to private change)
- _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_ fails at the point 
when we restart node1 with encryption being enabled and plaintext port 
shutdown. The inbound connection node2 is refused because of 
_InvalidLegacyProtocolMagic: Read 369295616, Expected -900387334_.
- _client_encryption_options:optional_ should be set to_ False_ in 
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl._

I don't see an issue with the change of optional to default value of True in 
cassandra.yaml but I suggest if we want to setup 
server_encryption_options:enabled to True as a default value, just to leave it 
commented and if the user tries to change it to false - to reject the change 
with a warning. I tried simply to comment server_encryption_options:enabled in 
cassandra.yaml and the tests are passing. 

[~jolynch], considering you mentioned there is already a ticket for improvement 
to land in 4.1 which suggests to split ServerEncryptionOptions class from 
EncryptionOptions class, I would personally leave this patch in the suggested 
way with minimum changes applied to the code as we are in code freeze. WDYT?
 











> server_encryption_options is not backwards compatible with 3.11
> ---------------------------------------------------------------
>
>                 Key: CASSANDRA-15262
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15262
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Local/Config
>            Reporter: Joey Lynch
>            Assignee: Joey Lynch
>            Priority: Normal
>             Fix For: 4.0, 4.0-alpha
>
>
> The current `server_encryption_options` configuration options are as follows:
> {noformat}
> server_encryption_options:
>     # set to true for allowing secure incoming connections
>     enabled: false
>     # If enabled and optional are both set to true, encrypted and unencrypted 
> connections are handled on the storage_port
>     optional: false
>     # if enabled, will open up an encrypted listening socket on 
> ssl_storage_port. Should be used
>     # during upgrade to 4.0; otherwise, set to false.
>     enable_legacy_ssl_storage_port: false
>     # on outbound connections, determine which type of peers to securely 
> connect to. 'enabled' must be set to true.
>     internode_encryption: none
>     keystore: conf/.keystore
>     keystore_password: cassandra
>     truststore: conf/.truststore
>     truststore_password: cassandra
>     # More advanced defaults below:
>     # protocol: TLS
>     # store_type: JKS
>     # cipher_suites: 
> [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
>     # require_client_auth: false
>     # require_endpoint_verification: false
> {noformat}
> A couple of issues here:
> 1. optional defaults to false, which will break existing TLS configurations 
> for (from what I can tell) no particularly good reason
> 2. The provided protocol and cipher suites are not good ideas (in particular 
> encouraging anyone to use CBC ciphers is a bad plan
> I propose that before the 4.0 cut we fixup server_encryption_options and even 
> client_encryption_options :
> # Change the default {{optional}} setting to true. As the new Netty code 
> intelligently decides to open a TLS connection or not this is the more 
> sensible default (saves operators a step while transitioning to TLS as well)
> # Update the defaults to what netty actually defaults to



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to