Securing Redis Client Connections
If you configure it, Redis Enterprise Software (RS) can use industry-standard encryption to protect your data in transit between a Redis client and RS. For this purpose, RS uses transport layer security (TLS) protocol, which is the more secure successor to SSL.
To enable TLS you must configure the RS cluster nodes, the database, and the client, as detailed below.
Configuration of the RS nodes
By default, each cluster node has a different set of self-signed certificates. These certificates can be replaced with your own certificate, preferably a certificate issued by an intermediate certificate authority (CA).
Configuration of the database
To encrypt the connection to the database endpoint with TLS, enter the contents the client certificate to the TLS field.
Note: Once TLS encryption is enabled for the database endpoint, the database does not accept unsecured connections. TLS encryption can significantly impact database throughput and latency.
Adding TLS CA signed certificates to the proxy
- The proxy is responsible for terminating the TLS connection
- Server certificate and key are located on /etc/opt/redislabs:proxy_cert.pem - server certificate thatproxy_key.pem - server certificate key*any update on these require a proxy restart
- Enabling of TLS is done via “ssl authentication” field in the UI. You are required to add a client-side certificate as a TLS connection is done via client certificate authentication (not just server side authentication).
Installing CA signed certificates high-level steps
Replace the RS server certificates and key on all nodes with the CA signed certificate, and restart the proxy.
Note: A certificate for the databases’ endpoint should be assigned for the same domain as the cluster name. For example, for a cluster with the name “redislabs.com” the certificate should be for “*.redislabs.com”.
Add the TLS client certificates in the UI including CA certificates and any intermediate certificates by chaining the certificate into one file (you can use a cat command to chain the certs).
On the client side make sure to import and trust the CA and intermediate certificates (you can chain the CA cert with intermediate as one file to use and import)
To connect to a database configured with TLS encryption, either use one of the Redis clients that inherently support SSL encryption, or use any Redis client and create a secured tunnel between the client machine and the RS nodes.
To learn which clients inherently support TLS, refer to this blog post.
Note: For security reasons, RS supports only the TLS protocol. Therefore, make sure that the Redis client or secured tunnel solution you use supports TLS, preferably TLS v1.2.
When using self-signed certificates on the cluster nodes, make sure to copy these certificates to the client machines as well, thereby enabling the client to validate the cluster nodes.
When using a certificate issued by an intermediate certificate authority (CA) on the cluster nodes, make sure that the CA root certificate is installed on the client machines.
Example how to secure client connection with TLS using stunnel
The instructions below explain how to use stunnel for setting up a secure tunnel between a client machine and the RS nodes when the client is running on Ubuntu, using the default RS nodes’ self-signed certificates, and a self-signed certificate on the client machine.
Install stunnel version 5 or higher on the client machine. Older versions of stunnel do not support the TLS protocol.
Create a self-signed certificate on the client machine:
Generate a private key by running the following commands:
sudo su openssl genrsa -out /etc/stunnel/keyclient.pem 4096
Generate a client certificate by running the following commands:
openssl req -new -x509 -key /etc/stunnel/keyclient.pem -out /etc/stunnel/cert.pem -days 1826
When prompted, enter the appropriate configuration details for the certificate.
Copy the RS node certificates from all nodes to the client machine. The certificates are saved in a file named proxy_cert.pem, which is stored in /etc/opt/redislabs in each node.
Rename the certificate files fetched from the RS nodes as certsvr.pem. For example: certsvr1.pem, certsvr2.pem.
Create a single file for all of the server certificates on the client machine, by running the following command from the OS CLI. For example:cat /etc/stunnel/certsvr1.pem /etc/stunnel/certsvr2.pem > /etc/stunnel/servercerts.pem
Configure stunnel for the connection to RS by using the steps below:
Create a redislabs.conf file in /etc/stunnel folder.
Make sure that the certificates that have been generated exist in the following folder: /etc/stunnel.
Edit the redislabs.conf content to look as follows:cert = /etc/stunnel/cert.pem key = /etc/stunnel/keyclient.pem cafile = /etc/stunnel/servercerts.pem verify = 2 delay = yes output = /tmp/stunnel.log pid = /tmp/stunnel.pid[redislabs] client = yes accept = 127.0.0.1:6379 connect = [database endpoint value]Where [database endpoint value] is the database endpoint as can be retrieved from RS.
Note: The value for the accept parameter is the local IP and port that is used for redirecting the traffic through the secure tunnel to the database endpoint configured in the connect parameter.
Copy the contents of the client certificate from cert.pem and enter them in the SSL Client Authentication field, in the RS UI, of the database you would like to secure. When done, be sure to save the change.
Start the stunnel service by running the following command:service stunnel restart
Note: Any change made to the stunnel configuration requires restarting the stunnel service.
Check the stunnel log file to verify that the connection is working properly. The log file is created under the root folder within the configuration mentioned above.
Test the connection to the Redis database from the client machine. You can use redis-cli to run commands on the client machine, and the commands are redirected from the local machine’s port 6379 to the RS database endpoint. Note that the connection to the Redis database is done through the local port; do not try to connect directly to the database endpoint.
TLS version information
RS fully supports TLS v1.2, but the version of TLS used depends on the connecting Redis client. If the client supports TLS v1.2, that version is used. If the client does not support TLS v1.2, you may end up using an older TLS version against RS. Therefore it is considered best practice to stay current on your client libraries for the most up to date security.
To set the minimum TLS version that can be used for encrypting the data in transit between a Redis client and a Redis Enterprise cluster, use the REST API or the following rladmin command:
rladmin> cluster config min_data_TLS_version [version, e.g. 1.2]
Note that if a client supports an older TLS version, the communication is not be allowed.