On May 8, 2014, at 5:20 PM, Demis Bellot <demis....@gmail.com
> Do you have an opinion on whether Redis Clients should bake SSL support in the clients directly to handle these types of scenarios? Or do you think transparent approaches like stunnel are the way to go?
Sidetracking a bit, I’m a fan of spiped: http://www.tarsnap.com/spiped.html
The default Redis approach to security is a pre-shared secret key. sipped uses the same approach, plus your connection will be fully encrypted. Only remote spiped clients with your pre-shared secret key can connect, so your connection is authenticated as well (modulo the security of your pre-shared secret key).
Just run one spiped in front of your Redis process, then another spiped on your client machines. Each client machine would talk to the localhost spiped, which would encrypt and forward your connections to the remote spiped in front of Redis. No CA. No PKI. No cryptic openssl commands. You can get the same effect with SSH tunnels as well (and SSH allows compression as well).
As for enabling SSL access directly in clients, it’s a bit of feature creep. SSL isn’t a feature of Redis, so SSL in the client is debatable.
As for stunnel, it has always been kinda equally bad at everything. A while ago, https://github.com/bumptech/stud
became a viable replacement, but it has been unmaintained since the parent company died. It’s possibly still very usable.
Another possibility is haproxy’s SSL mode. It’s good at sending data places.
But, I think the original question was from a windows user who wanted to access Redis without SSH. That could mean many different things. My first thought is: sounds like they are logging in to a Linux box to use redis-cli (or are required to use a Putty tunnel to connect their C# client), but they want to use Redis directly. Except, they don’t know the IP/Port of their Redis server. Potentially, they just need to ask for the local Redis IP/Port information. We’re just guessing at this point; not enough information to go on.