> Deprecating helps nothing for existing releases. We can’t/shouldn’t remove > the feature in existing releases.
The deprecation I'm proposing is intended to push people to configure their servers in a way that is more secure and maximizes compatibility with clients. Deprecating can help for existing releases - the better configuration already exists, and it's likely that users of dual-native-port optional SSL can use it. At the very least, users should be made aware of the risks of dual-native-port operation. Currently, if a user specifies the following server configuration: - client_encryption_options.enabled=true - client_encryption_options.optional=false - native_transport_port != native_transport_port_ssl then the server will still handle unencrypted traffic on native_transport_port. This feels like a security risk: it would be reasonable to interpret that this configuration requires all traffic to be encrypted. And if a user specifies this server configuration: - client_encryption_options.enabled=true - client_encryption_options.optional=true - native_transport_port != native_transport_port_ssl then clients can still send unencrypted traffic to native_transport_port_ssl, since the server handles optional encryption on this port. In this case, there are two ports that accept unencrypted traffic, one of which also accepts encrypted traffic. In both cases: - Clients configured to use SSL will discover non-SSL ports from system.peers_v2 and fail to connect to those hosts, causing single-connection sessions and no load balancing - Clients configured to use SSL will fail to interpret server-reported topology and status events because those events currently include non-SSL ports, causing user connection pools to incorrectly track cluster changes I'm proposing that in the dual-native-port case, we log a warning to advise clients to move to a single port, with the same values for enabled and optional. With a single port, users won't need to worry about native_transport_port always accepting unencrypted traffic. The peers_v2 system table and EVENT response messages will include ports that clients will be able to connect to regardless of their SSL configuration. I'm open to discussing other ways we could handle this, but I think the requirements are: - Maintain compatibility with existing clients (no new tables for discovering peers, etc.) - Ensure SSL and non-SSL sessions can continue to operate (with >1 pooled connections) without disruption Thanks to Stefan for his efforts looking into this more closely with me yesterday. We found out how this came about as well - when the project moved support dual-native-port in CASSANDRA-9590 <https://issues.apache.org/jira/browse/CASSANDRA-9590>, driver configurations were expected to include hard-coded ports for encrypted and unencrypted traffic. Then, when customizable per-host native ports came out in CASSANDRA-7554 <https://issues.apache.org/jira/browse/CASSANDRA-7544>, drivers were expected to discover the right native protocol port from the system table instead of hard-coding it. So this has been a problem since 4.0 for users running dual-native-port and clients requiring SSL. -- Abe
