SSL connections arrive for Redis on Compose

SSL secured connections to Redis are our most requested feature for Compose Redis, and now they are available and simple to add to any existing deployment.

Since we introduced Redis to the Compose platform, there's been regular requests for SSL encrypted connections into the speedy key/value database. Now, we're pleased to announce that Compose users can add one or more SSL encrypted portals to their Redis deployment. To be precise, we're offering TLS encrypted connections which superseded SSL; SSL is the more recognized name for the process though. All traffic routed to these SSL portals will be encrypted. Here's a couple of things to know first about Redis and SSL:

Redis and encrypted connections

Redis has traditionally used un-encrypted connections and there's no official support for SSL connections to the database. At Compose, we've offered an SSH portal to act as a tunnel for users wanting to secure their Redis connections. Using an SSH portal and tunnel is an effective way of encrypting the connections but it does take some setting up and a bit of key management. For some of our users, it was a good fit, but for others, it didn't have the simplicity of SSL connections.

SSL connections are easy to configure with much less setup and can come from anywhere you need to run a client. Rather than using cryptography to authenticate the connecting user, SSL connections can be configured to simply encrypt the connection and verify the server connected to is the one that was expected. This makes it attractive for many more scenarios. So much so that a number of solutions and even a provisional protocol rediss: has appeared in the Redis ecosystem.

Compose's engineering team set out to see if it would be possible to smoothly blend SSL support into our current connection mix for Redis. The result is an SSL portal which can be added to any Redis deployment. Let's see how you can start using it today.

Redis on Compose with TLS/SSL

By default, we'll continue to provision Redis with our standard non-SSL TCP portals. The main reason for this is to ensure users can connect with the redis-cli utility. This tool is part of the standard Redis distribution and has no ability to connect via the TLS portals. If you need to use redis-cli, we currently recommend either keeping an unencrypted portal for it to connect to or configure a utility like stunnel to tunnel the redis-cli connection.

If you don't need to use redis-cli, as the Compose browser and other tools are sufficient for your administrative needs, then you can remove all the unencrypted portals and purely have SSL portals.

To add an SSL supporting portal is simple: go to the Compose Console and head to the Security tab of a Compose Redis deployment. There you'll find there's a SSL Enabled checkbox next to the Add TCP Portal button. Check the checkbox, click the button and the new portal will be created.

Once you have added an SSL supporting portal, all you have to do is make sure your Redis driver supports SSL connections and use the rediss: connection string displayed in the URL. We've used the rediss: convention even though its support is variable.

If the Compose overview is showing a self-signed certificate, you will need to use that to verify your connection. If that isn't shown, then the SSL connections will be verified using a Let's Encrypt certificate generated specifically for the portal.

Connecting with Ruby

With the redis-rb RubyGem, simply use the "rediss:" connection string as is when creating the Redis connection like so:

irb(main):001:0> require 'redis'  
=> true
irb(main):002:0> redis=Redis.new(url:"rediss://admin:password@sl-eu-lon-2-portal.0.dblayer.com:11128")  
=> #<Redis client v4.0.1 for redis://sl-eu-lon-2-portal.0.dblayer.com:11128/0>
irb(main):003:0> redis.set("X",100)  
=> "OK"

If there is a certificate passed in the :ssl_params option like so:

redis=Redis.new(url:"rediss://admin:password@sl-eu-lon-2-portal.0.dblayer.com:11128",  
     :ssl_params=> { :ca_file => "./cert.crt" })

and that will be used to verify the connection.

Connecting with Node.js

The node-redis package also handles SSL connections. At it's simplest, and assuming that Let's Encrypt certificates are in use, this sequence of commands will get a connection:

const redis = require("redis");  
const { URL } = require('url');

let connectionString="rediss://admin:password@portal1128-0.raymond-redisston.compose-3.composedb.com:11128"

let client=redis.createClient("rediss://admin:password@sl-eu-lon-2-portal.0.dblayer.com:11128",  
          { tls: { servername: new URL(connectionString).hostname} }
 } );

Though it will emit a warning that you passed rediss: rather than redis:. You can edit the connection string down to redis: as it makes little difference. It's the passing of the tls hash that activates the encryption and sets the servername key to the hostname from the connection string. Many platforms fill in this value automatically; Node doesn't. It basically tells the server that it should use that name when looking up certificates. If not set, you'll see a verification error as the wrong certificate will be being used at the server end.

There is another situation when you can get a verification error - if you have a self-signed Redis portal. This is made apparent in the Compose console overview for your Redis deployment with a Self Signed Certificate panel being visible. You will need to copy and save that certificate and then pass it as a buffer to the createClient call like so:

const fs = require('fs');  
const redis = require("redis");

let connectionString="redis://admin:password@sl-eu-lon-2-portal.0.dblayer.com:11128"

let caCert = fs.readFileSync("./cert.crt")  
let client=redis.createClient(connectionString, { tls: { ca: caCert } });  

And you will now have that self-signed certificate verifying the connection.

Other languages and drivers

With so many different clients for Redis, it is somewhat difficult to survey them all with an eye to their SSL support. As we become aware of SSL supporting drivers, we'll be adding guidance to the documentation and to the Compose Grand Tour examples for Redis.

Redis-cli, Stunnel and other drivers

The Stunnel utility sets up a proxy service which performs the SSL encryption for an unencrypted client. We'll briefly cover setting it up on macOS here; the process is similar for other platforms.

First, install stunnel. Homebrew offers the simplest installation route: brew install stunnel. Once that's installed, it has to be configured in /usr/local/etc/stunnel/stunnel.conf. Open your preferred editor and add, as appropriate for your installation:

[redis-cli]
client=yes  
accept=127.0.0.1:6830  
connect=sl-eu-lon-2-portal.0.dblayer.com:11128  

This will set the stunnel process up to listen locally on port 6830 and connect out to the given server and port. Retrieve that information from your connection string.

The next step is to run stunnel which will immediately disappear into the background. Now we can run redis-cli and point it at port 6830. We'll also need the password from the connection string:

$ redis-cli -p 6830 -a password
127.0.0.1:6830> keys *  
 1) "x"
127.0.0.1:6830>  

This doesn't verify against a self-signed certificate. For that you'll need to add:

verify=2  
checkHost=sl-eu-lon-2-portal.0.dblayer.com  
CAfile=/usr/local/etc/stunnel/cert.crt  

With the appropriate hostname and path to the self-signed certificate for the Redis server.

Note that you can use stunnel to enable non-SSL enabled drivers to talk to the SSL supporting Compose Redis portals.

Finally

So now you can encrypt your traffic to Redis, either with native SSL support in the drivers or by tunneling an unencrypted connection through stunnel. It's easy to set up and we encourage users to look at using it to secure their Redis communications today.


Read more articles about Compose databases - use our Curated Collections Guide for articles on each database type. If you have any feedback about this or any other Compose article, drop the Compose Articles team a line at articles@compose.com. We're happy to hear from you.

attribution Aaron Paul