Using SSL in DSE drivers

DSE drivers support SSL-encrypted connections between the driver and server.

cassandra.yaml

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

DSE drivers support SSL-encrypted connections between the driver and server.

By default DataStax Enterprise (DSE) is configured to communicate with clients using an unencrypted binary protocol. This is convenient for getting started with DSE but is usually not suitable for production environments, especially those with clients communicating with DSE nodes over the public internet.

SSL in 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:

A typical SSL workflow consists of the following stages:

  1. The client opens a TCP connection to the server on the configured SSL port.
  2. An SSL handshake is initialized by the server, sending its public key (or certificate) to the client.
  3. The client uses that public key certificate to generate an encrypted session key and sends it back to the server.
  4. The server decrypts the message using its private key and retrieves the session key.
  5. All communication from that point on is encrypted using that session key.
Table 1. SSL certificate instructions
C/C++ C# Java Node.js* PHP Python Ruby

No identity verification

Clients with DSE drivers communicating securely with 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 doesn't 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.