Amazon Web Services announced today at redisconf that it is open sourcing encryption-in-transit for Redis, the leading in-memory key-value data store. Amazon ElastiCache for Redis added the encryption-in-transit feature last year to help our customers encrypt their Redis data sets and satisfy compliance requirements. We learned from our customers, and designed a solution that serves an important use case for them. Now we are contributing it to the Redis community so that anyone can secure real-time applications and encrypt all communications between clients and Redis servers, as well as between Redis servers (primary and read replica nodes).

Redis is a fast, open source, in-memory key-value data store for use as a database, cache, message broker, and queue, developed by a very active open-source community. It delivers sub-millisecond response times enabling millions of requests per second for real-time applications in gaming, ad-tech, financial services, healthcare, and IoT. Redis is a popular choice for caching, session management, real-time analytics, geospatial, chat/messaging, media streaming, and gaming leaderboards. It is

As developers increasingly rely on Redis to build real-time applications, there is pressing need to honor compliance requirements and protect the transmission of sensitive data such as Personal Identifiable Information (PII). For example, healthcare app developers need HIPAA compliance and encryption-in-transit to use Redis as a cache to transmit electronic health records for low-latency access. Similarly, developers using Redis as an in-memory data store to build consumer-facing mobile financial apps need encryption-in-transit to secure user and credit card data transmission.

However, open source Redis does not support encryption. Developers looking to build secure real-time applications with Redis need to rely on self-managed encryption solutions, such as SSL proxies, or commercial Redis offerings. In the SSL proxy approach, a proxy sits in front of the Redis server and encrypts and decrypts traffic between client and Redis server. For Redis clusters with multiple primaries (masters), additional proxies are required to encrypt communication across primaries. Setting up a proxy such as “stunnel” with a Redis cluster also requires that, for each node, multiple port forwardings must be set up correctly for cluster bus communication and communication across the replication links. This makes setup, ongoing maintenance, and scaling difficult and error-prone.

In contrast to the proxy-based solution, our contribution to open source Redis implements native encryption-in-transit support inside Redis. One of the key advantages of our approach for setting up encrypted connections is that the handshake process is non-blocking and extends the default connection negotiation process in Redis. When encryption-in-transit is enabled, the data synchronization between primaries and replicas (disk-based or diskless), as well as all cluster bus communication, is encrypted.

Our encryption-in-transit implementation encrypts using the Amazon s2n library. s2n is an open-source (Apache License 2.0) implementation of the TLS/SSL protocols that is designed to be simple, small, fast, and secure. s2n has a small and auditable code base, undergoes regular static analysis, fuzz-testing and penetration testing, includes positive and negative unit tests and end-to-end test cases, encrypts or erases plaintext data as quickly as possible, and avoids implementing rarely-used options and extensions.

You don’t need to modify your applications to start using the encryption-in-transit feature for Redis. You just need a client that supports encryption-in-transit, and then ensure that the relevant flag is set to “true.” There are a number of current clients that support encryption-in-transit, including Jedis for Java and redis-py for Python.

Besides encrypting all communications between clients and Redis servers, as well as between Redis servers (primary and read replica nodes), this new functionality also simplifies certificate renewals. In our implementation, renewing certificates does not require any downtime or restart of the cluster.

You can find the code and README on GitHub. You can participate by checking out the code and testing it, providing comments on the pull request, submitting issues, or submitting pull requests to add new features to the GitHub repository. We look forward to hearing from you!

Thanks also to Manoj Kumar for his contributions to this work.