[Feature Request] SSL Support

[GoogleCodeExporter]

Are there any plans to add SSL support to the roadmap?

This will help simplify deployments for those on cloud hosting.

Original issue reported on code.google.com by mjru...@gmail.com on 10 Oct 2009 at 3:49

[GoogleCodeExporter]

Why not tunnel trough SSH?

Original comment by calin....@gmail.com on 19 Oct 2009 at 7:05

[GoogleCodeExporter]

Hello, the way to go is to use a tunnel indeed.

Original comment by anti...@gmail.com on 23 Oct 2009 at 7:52

• Changed state: WontFix

[GoogleCodeExporter]

Tunnels work but they introduce more failure points into what is likely an 
already complex system.

MySQL's SSL support is fantastic and, in my opinion, adds a lot of value.

If someone built this, would you accept a patch?

Original comment by mjru...@gmail.com on 28 Oct 2009 at 2:50

[GoogleCodeExporter]

http://www.stunnel.org/ provides exactly what you need in a small codebase. It 
is a 
114KB binary on a Fedora Core rawhide system, x86_64.

There is no advantage in integrating this feature into redis, and a lot of 
disadvantages.

stunnel would indeed effectively be a point of failure. That's why I'd rather 
see 
stunnel fail and raw redis still work than the whole redis go down.

Why exactly would you want SSL to be included in redis?

Original comment by geoffroy...@gmail.com on 1 Mar 2010 at 2:46

[GoogleCodeExporter]

I'm not going to debate this any further, as Salvatore has already market this 
as WontFix.  The feature is not 
important is most cases and it adds a whole layer of complexity.  

However, if I need SSL I will fork Redis and add it myself.  I won't use 
tunnels.

Here's why:

- It's not inconceivable for hundreds or thousands of clients to be connected 
to a single Redis node (or cluster 
of nodes).
- Sometimes you need SSL.
- Maintaining hundreds or thousands of tunnels is ludicrous.

Yes, in general you really want to avoid the scenario where you need to wrap so 
many connections/ so much 
traffic in encryption but sometimes you have a large system and sensitive data 
and many nodes that happen  
to run on different cloud providers (i.e. communicate across untrusted 
networks).

The comment re: "stunnel is a single point of failure, would rather see stunnel 
fail and raw redis work than the 
whole redis go down" is missing the point.  Well-tested code that can speak SSL 
is not likely to break by virtue 
of its ability to do encrypted communication.  However, tunnels break all the 
time due to factors beyond the 
tunnelling software's control.

Original comment by mjru...@gmail.com on 1 Mar 2010 at 3:54

[GoogleCodeExporter]

OK, not to launch a long and useless debate, and if you want to implement SSL 
in a 
fork, that's your choice.

- No, thousands of clients is not inconceivable. redis is designed for that 
kind of 
load. However I don't think the overhead of a stunnel would be higher than the 
overhead of a SSL layer in redis. I said it.
- Sometimes you need SSL: I totally agree with you. That is why stunnel exists.
- Ludicrous is maybe excessive. You need one stunnel process per server, not 
per 
client.

"large system and sensitive data": do you want to forbid raw connections? 
remember 
that with redis, any client can access any data on the server, whether it can 
read 
connections or not.

If you want to use SSL authentication then I understand your need.
With thousands of clients, you might want to consider OpenVPN instead of 
OpenSSL on 
every service, as it makes initiating connections a LOT faster (avoiding SSL 
negociation at each connection is a BIG win).

"Well-tested code that can speak SSL is not likely to break by virtue 
of its ability to do encrypted communication.": no disrepect, but I'm not sure 
your 
SSL layer codebase will be of higher quality than stunnel's.

"However, tunnels break all the time due to factors beyond the 
tunnelling software's control.": why would stunnel+redis break more than 
redis-ssl? 
For my personal knowledge and professional uses, I'd genuinely like to know 
about 
that kind of issues.

Original comment by geoffroy...@gmail.com on 1 Mar 2010 at 7:18

[GoogleCodeExporter]

Everyone has the right to fork an open source project to meet their special
requirement. But I don't think it's the right way to participate with a project 
which
has active/open community. The reject of the feature request simply means you 
are
using it with a wrong way.

It's good to have ssl support, but event for ssl itself, it's much more 
complicated
than redis. This is against the objective of redis's simplicity. There are much
better/efficient/secure ways to your data/communication on different layers.

Original comment by mrdu...@gmail.com on 3 Mar 2010 at 12:19

[GoogleCodeExporter]

Agreed a tunnel would be more appropriate, no need to complicate the 97% use 
case with 
something that can easily be achieved with other (IMHO more appropriate) 
solutions.

Original comment by demis.be...@gmail.com on 3 Mar 2010 at 4:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

You can also use a client stunnel on the client machine. Then the redis client 
connects locally and does not have to be SSL-aware either.

Please visit http://www.stunnel.org/examples/generic_tunnel.html for 
instructions. I 
use this architecture for VNC and logging on a regular basis with convincing 
results.

And yes, SSH also also features such tunneling.

Original comment by geoffroy...@gmail.com on 3 Mar 2010 at 10:35

[GoogleCodeExporter]

Hi guys,

i couldn't use redis in my company just because there is no SSL communication 
support. I feel it adds value. 

Original comment by kkiran...@gmail.com on 14 Aug 2010 at 6:28

[GoogleCodeExporter]

I don't want anyone to tap the data conversation between redis and application 
server. It would be easier for someome to tap into the data, except we include 
custom encryption.

Original comment by gbpnk...@gmail.com on 21 May 2012 at 10:34

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Then you need a firewall to protect your data. Redis isn't one.

Original comment by serp...@gmail.com on 21 May 2012 at 11:10

[GoogleCodeExporter]

As someone that has had non stop issues with redis vs stunnel, I would be in 
the "please add this" court.  redis will replicate happily for a random period 
of time and will then just fail, requiring stunnel restarts.  its only redis 
that fails over the tunnels as other applications (mysql, custom code) is 
tunneling.

Original comment by p...@stopforumspam.com on 22 May 2012 at 7:07

[GoogleCodeExporter]

Just an FYI, My company has been using redis for a while now, and had issues 
with both stunnel, and running a software VPN. As a result, I've been working 
on adding SSL support directly to Redis. The company has graciously allowed me 
to release my changes to the community.

It is a work in progress, but works well so far. It is on github at 
https://github.com/bbroerman/ssl-redis

I also have an ssl enabled phpredis repository if you're using this with a PHP 
front-end.

Original comment by bbroerma...@gmail.com on 23 Jul 2012 at 8:25

[GoogleCodeExporter]

Thank you!!!  The stunnel replication in Redis has been driving me mad.  I 
wonder how easily this would port to 2.6

Original comment by p...@stopforumspam.com on 24 Jul 2012 at 2:35

[GoogleCodeExporter]

It shouldn't be too hard once it's available/stable. The whole SSL project took 
me about a week. I would definitely want to give it a try with Redis Cluster, 
when it's available and production ready. 
I've also been looking at HyperDex, since it's clustered and has immediate 
consistency and will be fully distributed very soon. I've spoken to their dev 
team, and they are open to implementing ssl support directly as well. I'm just 
waiting on their 0.7 release so I can get an equivalent to setnx and popl/popr 
functions.

Original comment by bbroerma...@gmail.com on 26 Jul 2012 at 4:55

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

If we cant get ssl, could we at least get tcp wrappers as a sign that redis 
will be adopting a security postuer at least as advanced as the late 90s?

Original comment by mrksch...@gmail.com on 3 Aug 2012 at 5:46

[GoogleCodeExporter]

Redis is not a daemon that should have a port open to the world. If you're 
using it like that, then you're doing it wrong.

Original comment by josiah.c...@gmail.com on 3 Aug 2012 at 7:10

[GoogleCodeExporter]

tcpwrappers, really? Do you believe in the Big Fat Pipes to validate IP 
addresses correctly?

Please, tcpwrappers is dead. No updates in years. It's just not offering decent 
security. Arch Linux even decided to drop it altogether.

If you want SSL, I don't see what the issue is with stunnel. If you actually 
face problems with stunnel, I'd love to hear them and if possible address them.

FWIW, I have professional interests in stunnel working well.

Original comment by geoffroy...@gmail.com on 3 Aug 2012 at 10:41

[GoogleCodeExporter]

How about a loopback cable directly to the redis servers?  That way I would not 
need stunnels.

Would that work?

Original comment by mrksch...@gmail.com on 4 Aug 2012 at 1:08

[GoogleCodeExporter]

I have issues with stunnel and redis.  I have both redis and mysql replicating 
over a stunnel and redis will frequently stop while mysql continues to 
replicate.  It can sometimes stay up for a month, sometimes for as little as a 
day.

Original comment by p...@stopforumspam.com on 4 Aug 2012 at 8:39

[GoogleCodeExporter]

I renamed the github repository for ssl-redis. It is now at: 
https://github.com/tritondigital/ssl-redis

There is also a PHP connector: https://github.com/tritondigital/ssl-phpredis

Original comment by bbroerma...@gmail.com on 6 Sep 2012 at 5:26

[GoogleCodeExporter]

FYI, I have updated the SSL redis fork and the phpredis client to the latest 
2.4.18. These are on my personal github repo (not on the tritondigital one): 

   redis: https://github.com/bbroerman30/ssl-redis
phpredis: https://github.com/bbroerman30/ssl-phpredis

Original comment by bbroerma...@gmail.com on 24 Dec 2012 at 5:26

[GoogleCodeExporter]

"Redis is not a daemon that should have a port open to the world. If you're 
using it like that, then you're doing it wrong."

And how are you going to replicate sensitive data between datacenters? Tunnels 
are not stable enough.

Original comment by normandi...@gmail.com on 1 Jul 2013 at 9:19

[GoogleCodeExporter]

"Redis is not a daemon that should have a port open to the world. If you're 
using it like that, then you're doing it wrong."

And how are you going to replicate sensitive data between datacenters? Tunnels 
are not stable enough.

xxxxx
Im gonna need a really long loopback cable . .  .

Original comment by mrksch...@gmail.com on 17 Jul 2013 at 5:41

[GoogleCodeExporter]

The status is already WontFix. Is there hope that additional supporting 
comments and votes can reopen this, or are we left with no option other than 
forks or rhetorics? Forking for just this feature doesn't make sense.

Original comment by gaurav.t...@gmail.com on 17 Jul 2013 at 6:02

[GoogleCodeExporter]

There is no hope.

As for cross-datacenter replication, there are a variety of SSH-based tunnels 
that will automatically reconnect, and which allow you to add compression to 
reduce bandwidth.

http://3scale.github.io/2012/07/25/fun-with-redis-replication/

Original comment by josiah.c...@gmail.com on 18 Jul 2013 at 4:35