Using SSL in DataStax drivers

Prerequisites

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

Configuration, Verification, and Workflow

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

By default Apache Cassandra™ and DataStax Enterprise (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 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.
The client verifies the identity of the server.
The server verifies the identity of the client.

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.

Table 1. SSL certificate instructions
C/C++	C#	Java	Node.js*	PHP	Python	Ruby

No identity verification

Clients with DataStax 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.