Using SSL in Cassandra drivers
DataStax-compatible drivers support SSL-encrypted connections between the driver and server.
Prerequisites
You need access to your cluster’s cassandra.yaml file.
The location of the cassandra.yaml file depends on the type of installation:
-
Package installations:
/etc/dse/cassandra/cassandra.yaml -
Tarball installations:
<installation_location>/resources/cassandra/conf/cassandra.yaml
This option isn’t supported for Astra DB because you can’t edit the cassandra.yaml file.
Configuration, Verification, and Workflow
DSE drivers support SSL-encrypted connections between the driver and server.
By default Cassandra, HCD, and DSE are configured to communicate with clients using an unencrypted binary protocol. This is convenient for getting started but is usually not suitable for production environments, especially those with clients communicating with Cassandra, HCD, or DSE over the public internet.
SSL in Cassandra and DSE can be configured different ways depending on the security requirements of the deployment. All configurations result in encrypted communication between the client and server.
SSL allows for different levels of identity verification:
-
No identity verification between the client and server.
A typical SSL workflow consists of the following stages:
-
The client opens a TCP connection to the server on the configured SSL port.
-
An SSL handshake is initialized by the server, sending its public key (or certificate) to the client.
-
The client uses that public key certificate to generate an encrypted session key and sends it back to the server.
-
The server decrypts the message using its private key and retrieves the session key.
-
All communication from that point on is encrypted using that session key.
No identity verification
Clients with Cassandra drivers communicating securely with Cassandra or DSE servers should validate the server’s identity. While most drivers support creating SSL connections to the server without identity verification, it is not recommended for production deployments.
When a secure browser contacts a web server, the browser verifies the identity of the server before sending it requests in case an attacker is masquerading as the web server. Secure communication to a bad actor defeats the purpose of configuring secure communication between the browser and web server in the first place.
Client verifies server
To verify the identity of a server, the driver must be configured with a list of trusted certificate authorities (CAs). When the driver receives the server’s SSL certificate during the SSL handshake, it checks that the certificate was signed by one of the registered CAs. If the certificate was not signed by a registered CA, the client checks that the signer was signed by one of the registered CAs. It continues through the signers until it finds one that is in the client’s list of trusted CAs.
If the client does not find a registered CA, identify verification fails.
Server verifies client
A server is configured to verify the identity of a client by setting the require_client_auth to true under client_encryption_options in cassandra.yaml.
This scenario requires clients be configured with their own certificates to send to the server upon request during the SSL handshake.
For more information, see Configure SSL for client-to-node connections
