Today we are happy to announce the availability of SSL Encryption for our fully managed ObjectRocket Redis service. Customers will now be able to connect to their Redis endpoints via SSL Encrypted connection strings for new ObjectRocket Redis instances. Take a look at this short video of Derek Johnson – Redis Product Manager at ObjectRocket and Jesse Lovelace – Sr. Software Developer at ObjectRocket discussing Redis and security along with details on the new SSL Encryption capability. Also, below is a transcript of the interview with Jesse on the capabilities.
Q: Who are you, and what do you do?
A: I’m Jesse Lovelace, and I’m a senior software developer at ObjectRocket.
Q: What does security mean for Redis? What is the philosophy Redis takes in regards to security?
A: Generally speaking, security for Redis means a fast, simple, authorization. For the most part, Redis relies on having the server behind some sort of firewall or extended application stack, instead of trying to provide a strong layer of security within Redis itself.
Q: What are some of the latest discussions around security features and capabilities within Redis?
A: There’s quite a discussion about if Redis should beef up its own internal security systems, or if it should remain a very fast, in-memory, datastructure server and just focus on that primarily. There are different camps on this, but I think the general consensus is that, is to keep the focus on being a very fast, in-memory datastructure server, as a way to keep Redis as good and fast at what it does, specifically.
Q: How does ObjectRocket Redis handle security today?
A: ObjectRocket Redis supports security by having a very simple authorization string that you have to use to access the server, and we also support access control lists implemented as firewall rules, which allow you to specify which hosts can actually contact the Redis instance. We also have the service net, which allows you to run Redis within a private virtual networking, which is not accessible from the outside internet.
Q: How does SSL encryption work, from a customer perspective?
A: When a customer creates a new Redis instance in the dashboard, they’ll be able to see their normal connection strings, and also a second set of ports for SSL. Since most clients don’t support SSL natively, customers will need to use a SSL tunnel to forward their Redis traffic over an encrypted connection.
Q: Can you describe the SSL architecture, and how these features work behind the scenes?
A: Well, Redis itself doesn’t support listening for SSL connections natively. In our architecture for Redis, we tunnel SSL connections and forward them to Redis at an endpoint that’s very close to the Redis server. The way we pull that off with a SSL compatible proxy that listens on on an SSL port; the client connects to that port, we verify the certificates, create the SSL connection, and that’s where the SSL connection terminates and the traffic is forwarded directly to the Redis server from there.
Q: What are the next steps for a customer using SSL to setup connection strings?
A: That varies based on the customer’s obligation. In a simple case, they’ll download a SSL software tunnel of choice, like stunnel, and set that up. In their settings, they’ll have that point to the new connection string for SSL. And in their initial connection, they’ll also verify the fingerprint of the SSL certificate, which will be available in their ObjectRocket dashboard so they know they’re connecting to the right instance.
Q: Will customers still have access to standard connection strings?
A: Yes, they’ll still have all their regular connection strings so they can connect to Redis directly, without a SSL tunnel.
Q: Is there any expected performance impact to using SSL encryption?
A: For us, the impact on performance is actually negligible once the connection is established. Modern CPUs and operating systems have very fast SSL libraries, so once you’ve done the initial SSL handshake, your data flows at almost normal speed. As long as you keep your connection strings open, you’re not going to notice any difference in performance. But if you are constantly creating and disconnecting from the Redis server you will notice that additional overhead, created by redoing the SSL handshake negotiation every time.
Q: Are there any other feature limitations of SSL encrypted Redis?
A: No.
Q: Which Redis instances is SSL available on?
A: SSL will initially be available to all new instances that are created. We do have plans to enable a migration of legacy instances to have SSL availability, without any customer downtime.
Q: Are there any migration steps the customer needs to take to enable SSL on existing Redis instances?
A: Nope, we will handle that all internally. We will handle all migrations in such a way that their connection strings aren’t terminated, their hostnames remain the same, their ports remain the same, to create a seamless experience for the customer.
Additional Resource
- ObjectRocket Support (immediately opens a ticket with our support team)
- ObjectRocket Redis SSL Encryption Documentation
- Redis.io Security Documentation
- ObjectRocket Redis SSL Encryption Announcement
- ObjectRocket Redis and Security Blog
