Redis SSL support

[antirez]

HQ for ideas / proposals / code about Redis and SSL support.

[bbroerman30]

I'll be looking over the code I wrote over Christmas... I have Dec 18th through Jan 2nd off, so I should have plenty of time finish testing 2.6, and get 2.7 and 2.8 updates merged in. I'll also see if I can create a new branch directly from yours and merge my changes into it. (I'll be working on things in that order probably). Should I start with your 2.6, 2.7 or 2.8?

[bbroerman30]

I'll be looking over the code I wrote over Christmas... I have Dec 18th through Jan 2nd off, so I should have plenty of time finish testing 2.6, and get 2.7 and 2.8 updates merged in. I'll also see if I can create a new branch directly from yours and merge my changes into it. (I'll be working on things in that order probably). Should I start with your 2.6, 2.7 or 2.8?

[antirez]

Thanks @bbroerman30, ideally the best thing is to start from the "unstable" branch. Back porting will not be hard and I can take care of it, but for new stuff it's ideal to hack on the development tree.

[antirez]

Thanks @bbroerman30, ideally the best thing is to start from the "unstable" branch. Back porting will not be hard and I can take care of it, but for new stuff it's ideal to hack on the development tree.

[bbroerman30]

I'll fork off of that then, and once I get 2.6 tested (and go through the code and remember what I did and why) I'll start looking at the unstable branch and making changes in there. I'll hold off on 2.7 and 2.8 updates on my side...

[bbroerman30]

I'll fork off of that then, and once I get 2.6 tested (and go through the code and remember what I did and why) I'll start looking at the unstable branch and making changes in there. I'll hold off on 2.7 and 2.8 updates on my side...

[tarcieri]

Just wanted to say thank you for opening this issue!

To anyone who might happen to ask "why not stunnel/stud/spiped/(insert proxy here)/etc" we operate nearly a hundred of these tunnels and have to manage the overhead of provisioning individual certificates, trust stores, adding new certificates to these trust stores for key rotation, ensuring that apps, tunnels, and Redis are started up and taken down in awareness of this fact, and have to implement key rotation within these constraints.

It's very easy to say "just use stunnel". If you have any actual experience maintaining a highly available, secure infrastructure using dozens or hundreds of stunnels, I think you'll quickly become aware the reality of the situation is: easier said than done.

Native SSL support would eliminate all sorts of operational overhead we have around encrypting all of our Redis connections.

Last but not least, I'll leave you the quotes reel from when I originally told my coworkers that there may be a solution on the horizon for native SSL support in Redis:

"This is great."
"YES DIE STUNNELS DIE"
"Nice!"
"DO THIS OH GOD PLEASE DO THIS"
"Very nice!"
"Yes yes yes."

These quotes come from people operationally responsible for maintaining our stunnel-based infrastructure. I want to make these people's lives easier.

[tarcieri]

Just wanted to say thank you for opening this issue!

To anyone who might happen to ask "why not stunnel/stud/spiped/(insert proxy here)/etc" we operate nearly a hundred of these tunnels and have to manage the overhead of provisioning individual certificates, trust stores, adding new certificates to these trust stores for key rotation, ensuring that apps, tunnels, and Redis are started up and taken down in awareness of this fact, and have to implement key rotation within these constraints.

It's very easy to say "just use stunnel". If you have any actual experience maintaining a highly available, secure infrastructure using dozens or hundreds of stunnels, I think you'll quickly become aware the reality of the situation is: easier said than done.

Native SSL support would eliminate all sorts of operational overhead we have around encrypting all of our Redis connections.

Last but not least, I'll leave you the quotes reel from when I originally told my coworkers that there may be a solution on the horizon for native SSL support in Redis:

"This is great."
"YES DIE STUNNELS DIE"
"Nice!"
"DO THIS OH GOD PLEASE DO THIS"
"Very nice!"
"Yes yes yes."

These quotes come from people operationally responsible for maintaining our stunnel-based infrastructure. I want to make these people's lives easier.

[fdr]

Ditto the above, and doubly so for the client drivers. Server operators can (sort of) cope, but getting clients to use stunnel is a considerably bigger chore for all involved.

I'll happily take any implementation over none, but regardless here are some ideas I experimented with.

In a nutshell, I decided SCRAM-SHA1-PLUS with tls-server-end-point channel-binding would let me fix the most Redis issues at once with the least work. This delivers some compelling advantages when the TLS and Authentication mechanisms of an application can interact.

As for implementation, I wrote some prototype code for this (in Go, presuming it'd have to be a proxy anyway) and was getting some traction, but then had to go work on something else. If there's sufficient interest, I may revisit that decision. Regardless, here is why I made these choices:

• Detecting MITM is simplified.
• Doesn't break TLS concentrators.
• Avoids persistent breaks via challenge-response.

From first to last:

Detecting MITM is simplified

This is a feature of "channel-binding". In a nutshell, the pre-shared secret (password) is mixed with both the client and server's view of the TLS state (e.g. presented public key) on the connection. A mismatch (e.g. decrypt-and-re-encrypt with another key) will present as an authentication failure.

This is a very cool way to avoid the complexity of certificate pinning or CAs provided one continues to use the password/pre-shared-key model, as I suspect pre-shared-keys will remain very useful for a long time.

This is known by the lingo SCRAM-SHA1-PLUS. In my prototype, deviating from the standard, to only support this "PLUS" variant, and not the non-channel-bound version.

Doesn't break TLS concentrators

This has to do with the choice of tls-server-end-point.

In my prototype, deviating from the standard, I was going to skip the otherwise mandatory support for tls-unique, as with a proxy design my own program was itself akin to a TLS concentrator. What this amounts to is mixing in the fingerprint of the public key encrypting the channel into the HMACs passed around (see the "algorithm" section).

Avoids persistent breaks via challenge-response

If one manages to get ahold of a decrypted session, salted challenge-response avoids the long-lived password from being compromised. This is a common feature of older methods like DIGEST-MD5.

SCRAM has some useful properties, but the most useful is that it's simpler to implement than even venerable older methods. Otherwise interesting but not as important to me is that it supports holding securely derived keys on the server, so that one does not compromise the password if the server reads out its own passwd-ish file.

The algorithm

It is seen with explanation of the notation in the SCRAM rfc linked above, but here's a taste (and lets you find the section):

     SaltedPassword  := Hi(Normalize(password), salt, i)
     ClientKey       := HMAC(SaltedPassword, "Client Key")
     StoredKey       := H(ClientKey)
     AuthMessage     := client-first-message-bare + "," +
                        server-first-message + "," +
                        client-final-message-without-proof
     ClientSignature := HMAC(StoredKey, AuthMessage)
     ClientProof     := ClientKey XOR ClientSignature
     ServerKey       := HMAC(SaltedPassword, "Server Key")
     ServerSignature := HMAC(ServerKey, AuthMessage)

[fdr]

Ditto the above, and doubly so for the client drivers. Server operators can (sort of) cope, but getting clients to use stunnel is a considerably bigger chore for all involved.

I'll happily take any implementation over none, but regardless here are some ideas I experimented with.

In a nutshell, I decided SCRAM-SHA1-PLUS with tls-server-end-point channel-binding would let me fix the most Redis issues at once with the least work. This delivers some compelling advantages when the TLS and Authentication mechanisms of an application can interact.

As for implementation, I wrote some prototype code for this (in Go, presuming it'd have to be a proxy anyway) and was getting some traction, but then had to go work on something else. If there's sufficient interest, I may revisit that decision. Regardless, here is why I made these choices:

• Detecting MITM is simplified.
• Doesn't break TLS concentrators.
• Avoids persistent breaks via challenge-response.

From first to last:

Detecting MITM is simplified

This is a feature of "channel-binding". In a nutshell, the pre-shared secret (password) is mixed with both the client and server's view of the TLS state (e.g. presented public key) on the connection. A mismatch (e.g. decrypt-and-re-encrypt with another key) will present as an authentication failure.

This is a very cool way to avoid the complexity of certificate pinning or CAs provided one continues to use the password/pre-shared-key model, as I suspect pre-shared-keys will remain very useful for a long time.

This is known by the lingo SCRAM-SHA1-PLUS. In my prototype, deviating from the standard, to only support this "PLUS" variant, and not the non-channel-bound version.

Doesn't break TLS concentrators

This has to do with the choice of tls-server-end-point.

In my prototype, deviating from the standard, I was going to skip the otherwise mandatory support for tls-unique, as with a proxy design my own program was itself akin to a TLS concentrator. What this amounts to is mixing in the fingerprint of the public key encrypting the channel into the HMACs passed around (see the "algorithm" section).

Avoids persistent breaks via challenge-response

If one manages to get ahold of a decrypted session, salted challenge-response avoids the long-lived password from being compromised. This is a common feature of older methods like DIGEST-MD5.

SCRAM has some useful properties, but the most useful is that it's simpler to implement than even venerable older methods. Otherwise interesting but not as important to me is that it supports holding securely derived keys on the server, so that one does not compromise the password if the server reads out its own passwd-ish file.

The algorithm

It is seen with explanation of the notation in the SCRAM rfc linked above, but here's a taste (and lets you find the section):

     SaltedPassword  := Hi(Normalize(password), salt, i)
     ClientKey       := HMAC(SaltedPassword, "Client Key")
     StoredKey       := H(ClientKey)
     AuthMessage     := client-first-message-bare + "," +
                        server-first-message + "," +
                        client-final-message-without-proof
     ClientSignature := HMAC(StoredKey, AuthMessage)
     ClientProof     := ClientKey XOR ClientSignature
     ServerKey       := HMAC(SaltedPassword, "Server Key")
     ServerSignature := HMAC(ServerKey, AuthMessage)

[bbroerman30]

Status Update: I have a clone of antirez/redis and am working on merging in the changes from my 2.6.17 branch into the trunk. I started with a 3-way diff, and merged everything I could from that, and then started compiling and working out all the compile errors. I have the initial merge done, and checked into my clone. It compiles, and I can connect with redis-cli but there are still critical errors reported by the self test. I'll be working over the next week (while i'm on vacation) to try and sort these out. After my vacation is over, I'll still be able to work some evenings and weekends until it's all working...

[bbroerman30]

Status Update: I have a clone of antirez/redis and am working on merging in the changes from my 2.6.17 branch into the trunk. I started with a 3-way diff, and merged everything I could from that, and then started compiling and working out all the compile errors. I have the initial merge done, and checked into my clone. It compiles, and I can connect with redis-cli but there are still critical errors reported by the self test. I'll be working over the next week (while i'm on vacation) to try and sort these out. After my vacation is over, I'll still be able to work some evenings and weekends until it's all working...

[badboy]

@bbroerman30 Is this work already public?

[badboy]

@bbroerman30 Is this work already public?

[tarcieri]

@bbroerman30 great to hear!

[tarcieri]

@bbroerman30 great to hear!

[bbroerman30]

Was able to generate a self-signed certificate, add it to the root store, connect a client to a server with SSL, verified that it would not connect without, verified it checked the certificate, connected a slave with SSL, and verified it checked the certificate and validated the configured common name... Also, ran the runtest-sentinel and runtest-cluster with minimal errors without SSL (the errors I had were probably due to the tiny box I'm running this on... it's a Athlon XP 2600 with 1G ram) I will run them with SSL over the next couple days.

[bbroerman30]

Was able to generate a self-signed certificate, add it to the root store, connect a client to a server with SSL, verified that it would not connect without, verified it checked the certificate, connected a slave with SSL, and verified it checked the certificate and validated the configured common name... Also, ran the runtest-sentinel and runtest-cluster with minimal errors without SSL (the errors I had were probably due to the tiny box I'm running this on... it's a Athlon XP 2600 with 1G ram) I will run them with SSL over the next couple days.

[bbroerman30]

@badboy It's in my fork of redis (in the trunk). I checked in the changes last night to that repo. I have also been testing my sslredis 2.6.17 to make sure it's working properly as well... I'm using a copy of antirez's trunk for baselines on the unstable, and my sslredis 2.6.17 as the baseline for SSL...

[bbroerman30]

@badboy It's in my fork of redis (in the trunk). I checked in the changes last night to that repo. I have also been testing my sslredis 2.6.17 to make sure it's working properly as well... I'm using a copy of antirez's trunk for baselines on the unstable, and my sslredis 2.6.17 as the baseline for SSL...

[badboy]

Thanks for your work.

[badboy]

Thanks for your work.

[bbroerman30]

still have work to do... unstable branch is having issues on initial replication to slave. 2.6.17 was working perfectly, so I'm trying to figure out the differences.

[bbroerman30]

still have work to do... unstable branch is having issues on initial replication to slave. 2.6.17 was working perfectly, so I'm trying to figure out the differences.

[bbroerman30]

ok, got initial replication happening (simple case, full dump) and continual replication between a master and 1 slave. Looking through the code, I think after I get it all working, I want to refactor... creating a structure that will replace the socket file descriptor. The structure should contain the fd, the anetSSLConnection, and a flag that indicates which to look at. Each place the fd (client.fd, server.fd, server.repl_transfer_s, etc.) is used it will be changed to this structure. I'm also thinking of a helper function that encapsulates SSL_write and write, as well we SSL_read and read. This new function will take the new structure.

[bbroerman30]

ok, got initial replication happening (simple case, full dump) and continual replication between a master and 1 slave. Looking through the code, I think after I get it all working, I want to refactor... creating a structure that will replace the socket file descriptor. The structure should contain the fd, the anetSSLConnection, and a flag that indicates which to look at. Each place the fd (client.fd, server.fd, server.repl_transfer_s, etc.) is used it will be changed to this structure. I'm also thinking of a helper function that encapsulates SSL_write and write, as well we SSL_read and read. This new function will take the new structure.

[bbroerman30]

Having issues getting a cluster running... Same error with the standard (unmodififed) unstable version as with my SSL version. All of the instances of redis server crash with a core dump when I tell the ./redis-trib.rb script to save the configuration. I'm running on a small Athlon XP 2600 box with 1Gb of ram, running stock Ubuntu 14.10 and following the instructions from the Redis cluster tutorial. I only have a couple days left of vacation, and would like to get this initial code change validated.

I don't really want to get into a refactor without knowing that the existing code is working.

[bbroerman30]

Having issues getting a cluster running... Same error with the standard (unmodififed) unstable version as with my SSL version. All of the instances of redis server crash with a core dump when I tell the ./redis-trib.rb script to save the configuration. I'm running on a small Athlon XP 2600 box with 1Gb of ram, running stock Ubuntu 14.10 and following the instructions from the Redis cluster tutorial. I only have a couple days left of vacation, and would like to get this initial code change validated.

I don't really want to get into a refactor without knowing that the existing code is working.

[badboy]

@bbroerman30 Can you figure it out yourself or is there anything we can help with?

[badboy]

@bbroerman30 Can you figure it out yourself or is there anything we can help with?

[bbroerman30]

I'm pretty sure it's related to the small size of the linux box I have available... Do you have a box that has successfully run a small cluster before? If so, I would appreciate someone helping with running a simple cluster test

[bbroerman30]

I'm pretty sure it's related to the small size of the linux box I have available... Do you have a box that has successfully run a small cluster before? If so, I would appreciate someone helping with running a simple cluster test

[badboy]

I've got some DigitalOcean credit left and access to other virtual servers. Just tell me what to do and I spin up some instances.

[badboy]

I've got some DigitalOcean credit left and access to other virtual servers. Just tell me what to do and I spin up some instances.

[bbroerman30]

Can you give it a quick try with regular redis unstable? The instructions i was following are here: http://redis.io/topics/cluster-tutorial

[bbroerman30]

Can you give it a quick try with regular redis unstable? The instructions i was following are here: http://redis.io/topics/cluster-tutorial

[badboy]

Will do in a moment

[badboy]

Will do in a moment

[badboy]

Created the cluster with redis-trib. Tested with redis-cli -c. Everything seems to work fine so far.

P.S.: I'm also available on IRC (freenode)

[badboy]

Created the cluster with redis-trib. Tested with redis-cli -c. Everything seems to work fine so far.

P.S.: I'm also available on IRC (freenode)

[bbroerman30]

@badboy Awesome. Can you try with the ssl version? Without SSL enabled. You can get it from my repo at https://github.com/bbroerman30/redis. I'm in and out today as it's the last day of my vacation, and I'm trying to get a bunch of other things done before I go back to the normal grind. I really appreciate your help!!!

[bbroerman30]

@badboy Awesome. Can you try with the ssl version? Without SSL enabled. You can get it from my repo at https://github.com/bbroerman30/redis. I'm in and out today as it's the last day of my vacation, and I'm trying to get a bunch of other things done before I go back to the normal grind. I really appreciate your help!!!

[badboy]

Any hints for setting up the ssl cert and key?

Update: Sorry, over-read that I should test without SSL, even easier then.

[badboy]

Any hints for setting up the ssl cert and key?

Update: Sorry, over-read that I should test without SSL, even easier then.

[bbroerman30]

yeah. Setting SSL isn't too bad, except that the Ruby and Tcl clients aren't set up for SSL. I created my own self-signed private key and cert, then installed the cert into the trusted root store on the box. Setting up the trusted root store depends on the OS...

After that, I set up the redis.conf like:
ssl true # turn on SSL (makes all connections require ssl)
ssl_ca_root_dir /usr/share/ca-certificates # The trusted root store for openSSL.
ssl_cert_file /home/brad/redis/cacert.pem # The self-signed cert the server is running with.
ssl_pk_file /home/brad/redis/privkey.pem # The private key I created the cert with.
ssl_cert_pass Pidb95 # Password for the private key/cert.
ssl_dhk_file /home/brad/redis/dHParam.pem # Diffie-Hellman key file .
ssl_cert_common_name bbroerman.net # This is used by the slaves to validate the CN in the cert (as most slaves connect by IP and not name. This is optional)

[bbroerman30]

yeah. Setting SSL isn't too bad, except that the Ruby and Tcl clients aren't set up for SSL. I created my own self-signed private key and cert, then installed the cert into the trusted root store on the box. Setting up the trusted root store depends on the OS...

After that, I set up the redis.conf like:
ssl true # turn on SSL (makes all connections require ssl)
ssl_ca_root_dir /usr/share/ca-certificates # The trusted root store for openSSL.
ssl_cert_file /home/brad/redis/cacert.pem # The self-signed cert the server is running with.
ssl_pk_file /home/brad/redis/privkey.pem # The private key I created the cert with.
ssl_cert_pass Pidb95 # Password for the private key/cert.
ssl_dhk_file /home/brad/redis/dHParam.pem # Diffie-Hellman key file .
ssl_cert_common_name bbroerman.net # This is used by the slaves to validate the CN in the cert (as most slaves connect by IP and not name. This is optional)

[badboy]

Ok, got it compiled and running. 6 instances (3 master, 3 slave), but for some reason I can't create a cluster, it hangs on CLUSTER MEET. (but no crash)

[badboy]

Ok, got it compiled and running. 6 instances (3 master, 3 slave), but for some reason I can't create a cluster, it hangs on CLUSTER MEET. (but no crash)

[badboy]

Ok, it does crash. Upstart was just fast enough to respawn the process without me noticing.
Log output: https://gist.github.com/badboy/9e16cf070de82c9309be

[badboy]

Ok, it does crash. Upstart was just fast enough to respawn the process without me noticing.
Log output: https://gist.github.com/badboy/9e16cf070de82c9309be

[badboy]

For some reason this gets called even though I did not enable ssl:
https://github.com/bbroerman30/redis/blob/unstable/src/cluster.c#L1928

[badboy]

For some reason this gets called even though I did not enable ssl:
https://github.com/bbroerman30/redis/blob/unstable/src/cluster.c#L1928

[bbroerman30]

That error should be fixed now. I got a bit more picky (as i should have been initially) on the initial setting of link->ssl's attributes on createClusterLink() and setting it's properties when an SSL connection is made. I wish I could run it over here (even the original unmodified unstable won't run cluster on my box)

[bbroerman30]

That error should be fixed now. I got a bit more picky (as i should have been initially) on the initial setting of link->ssl's attributes on createClusterLink() and setting it's properties when an SSL connection is made. I wish I could run it over here (even the original unmodified unstable won't run cluster on my box)

[badboy]

It works now as expected. redis-trib can create a cluster and I can set keys as expected.

Your local machine must be really underpowered if it doesn't work. I could give you a small virtual machine to test on if you want.

[badboy]

It works now as expected. redis-trib can create a cluster and I can set keys as expected.

Your local machine must be really underpowered if it doesn't work. I could give you a small virtual machine to test on if you want.

[bbroerman30]

Thanks. I may have time tomorrow to run through tests. The box I have here is one of the kids old computers. Athlon XP 2600 with 1G ram, running Ubuntu 14.10 32 bit.

[bbroerman30]

Thanks. I may have time tomorrow to run through tests. The box I have here is one of the kids old computers. Athlon XP 2600 with 1G ram, running Ubuntu 14.10 32 bit.

[badboy]

Ok, just drop me a note if you want a box to test on.

[badboy]

Ok, just drop me a note if you want a box to test on.

[bbroerman30]

Thanks! I'm running through make test currently with my latest changes, with SSL on. I had 1 error with it off (got the same error on the original version, so I'm not worried) Then I am going to try runtest-sentinel and runtest-cluster, and see what I get. In the morning, after my other stuff, I'll see if I can get a cluster going here one more time. If I can't I'll drop you a note.

[bbroerman30]

Thanks! I'm running through make test currently with my latest changes, with SSL on. I had 1 error with it off (got the same error on the original version, so I'm not worried) Then I am going to try runtest-sentinel and runtest-cluster, and see what I get. In the morning, after my other stuff, I'll see if I can get a cluster going here one more time. If I can't I'll drop you a note.

[bbroerman30]

Do you (or anyone here) know where this functionality resides? The failed test on normal mode is:
Can't detect write load from background clients.

It worked with SSL turned on, so I imagine I have a typo somewhere.

[bbroerman30]

Do you (or anyone here) know where this functionality resides? The failed test on normal mode is:
Can't detect write load from background clients.

It worked with SSL turned on, so I imagine I have a typo somewhere.

[bbroerman30]

I'm assuming runtest-sentinel and runtest-cluster don't use the main redis.conf in the root directory (and therefore don't use SSL)... Everything is working there. I'm going to look over the tcl scripts to see if I can get them to do SSL

[bbroerman30]

I'm assuming runtest-sentinel and runtest-cluster don't use the main redis.conf in the root directory (and therefore don't use SSL)... Everything is working there. I'm going to look over the tcl scripts to see if I can get them to do SSL

[badboy]

None of the tests use the redis.conf in the main directory.
The tests create the config on-the-fly, see https://github.com/bbroerman30/redis/blob/unstable/tests/cluster/run.tcl#L14-L17

Please save yourself and us some time and try to follow the existing code layout. That means 4-space indentation, ifs like if (condition) { ... and LF (\n) line endings (not Windows-like \r\n)

[badboy]

None of the tests use the redis.conf in the main directory.
The tests create the config on-the-fly, see https://github.com/bbroerman30/redis/blob/unstable/tests/cluster/run.tcl#L14-L17

Please save yourself and us some time and try to follow the existing code layout. That means 4-space indentation, ifs like if (condition) { ... and LF (\n) line endings (not Windows-like \r\n)

[bbroerman30]

The one issue that I see currently is getting the TCL client to use SSL. I've done a PHP client, and I'm starting on a Java client, but I don't know TCL.

[bbroerman30]

The one issue that I see currently is getting the TCL client to use SSL. I've done a PHP client, and I'm starting on a Java client, but I don't know TCL.

[tarcieri]

I'd be happy to help add SSL support to redis-rb

[tarcieri]

I'd be happy to help add SSL support to redis-rb

[bbroerman30]

Cool. Googling, it seems that for the TCL side, we just need to use http://www.sensus.org/tcl/tls.htm#tls::import (but that may be over-simplifying)

[bbroerman30]

Cool. Googling, it seems that for the TCL side, we just need to use http://www.sensus.org/tcl/tls.htm#tls::import (but that may be over-simplifying)

[uhoh-itsmaciek]

@bbroerman30 Thanks for your great work here. Can you link the PHP or Java client patch as a reference for how to do SSL for Redis in a client? I'm thinking of doing a PR for https://github.com/garyburd/redigo if I can find some time.

[uhoh-itsmaciek]

@bbroerman30 Thanks for your great work here. Can you link the PHP or Java client patch as a reference for how to do SSL for Redis in a client? I'm thinking of doing a PR for https://github.com/garyburd/redigo if I can find some time.

[itamarhaber]

I have a list here that includes Java and PHP: https://redislabs.com/blog/secure-redis-ssl-added-to-redsmin-and-clients - would love to have go there too

[itamarhaber]

I have a list here that includes Java and PHP: https://redislabs.com/blog/secure-redis-ssl-added-to-redsmin-and-clients - would love to have go there too

[bbroerman30]

Just an FYI: I have updated my ssl-redis to include the latest stable releases of 2.8.24 and 3.0.6, and am working to merge in the latest 3.2 stable tag. In 2.8.24 and 3.0.6 I've tested basic communication, replication, and sentinel. I haven't been able to get the SSL version of the Ruby gem to work yet, so I've tested cluster in 3.0.6 without SSL, but not yet with it.. I've also updated the phpredis connector to be in sync with the latest release, and have an SSL enabled version of jedis available as well. Still working (in my spare time) to get these fully tested. I did run their internal test suite, though, in SSL as well as plain.

[bbroerman30]

Just an FYI: I have updated my ssl-redis to include the latest stable releases of 2.8.24 and 3.0.6, and am working to merge in the latest 3.2 stable tag. In 2.8.24 and 3.0.6 I've tested basic communication, replication, and sentinel. I haven't been able to get the SSL version of the Ruby gem to work yet, so I've tested cluster in 3.0.6 without SSL, but not yet with it.. I've also updated the phpredis connector to be in sync with the latest release, and have an SSL enabled version of jedis available as well. Still working (in my spare time) to get these fully tested. I did run their internal test suite, though, in SSL as well as plain.

[antirez]

@bbroerman30 3.2 (which is very similar to unstable) port is a good news in order for the feature to be reviewed & eventually merged. During the latest two Redis meetings I received a lot of negative feedbacks about merging native SSL support into Redis, but yet I would merge it if the implementation is almost completely decoupled of the Redis core and just an opt-in at compile time, not enabled by default. I'll review your set of changes in the next weeks.

[antirez]

@bbroerman30 3.2 (which is very similar to unstable) port is a good news in order for the feature to be reviewed & eventually merged. During the latest two Redis meetings I received a lot of negative feedbacks about merging native SSL support into Redis, but yet I would merge it if the implementation is almost completely decoupled of the Redis core and just an opt-in at compile time, not enabled by default. I'll review your set of changes in the next weeks.

[antirez]

@bbroerman30 also, thanks for your efforts so far, that's great. This motivates me into looking into the result and evaluating with care if we can merge your work.

[antirez]

@bbroerman30 also, thanks for your efforts so far, that's great. This motivates me into looking into the result and evaluating with care if we can merge your work.

[tarcieri]

@antirez can you share any examples of the negative feedback you received during the Redis meetings?

[tarcieri]

@antirez can you share any examples of the negative feedback you received during the Redis meetings?

[timoc]

I guess i am late to the party here, and not yet looked into the proposed implementation, looking forward to evaluating it, but throwing in my 5 cents to the discussion.

Why not implement this feature in the sentinel? My rationale being:
1 - separate process
2 - ssl usually only required for multiple hosts/clusters
3 - certs etc stored outside of redis - sentinel can handle all transport layer auth shenanigans.
4 - sentinel is a better place to automatically manage the localhost tunnels.
5 - little/no change in clients required other than sentinel compatibility which they need anyway.
6 - guessing here but assuming it is simpler to implement/maintain? (i see talk of having to re-factor the whole I/O layer for the current proposal)

[timoc]

I guess i am late to the party here, and not yet looked into the proposed implementation, looking forward to evaluating it, but throwing in my 5 cents to the discussion.

Why not implement this feature in the sentinel? My rationale being:
1 - separate process
2 - ssl usually only required for multiple hosts/clusters
3 - certs etc stored outside of redis - sentinel can handle all transport layer auth shenanigans.
4 - sentinel is a better place to automatically manage the localhost tunnels.
5 - little/no change in clients required other than sentinel compatibility which they need anyway.
6 - guessing here but assuming it is simpler to implement/maintain? (i see talk of having to re-factor the whole I/O layer for the current proposal)

[badboy]

@timoc Are you talking about Redis Sentinel?

[badboy]

@timoc Are you talking about Redis Sentinel?

[timoc]

@badboy Yes.

[timoc]

@badboy Yes.

[badboy]

@timoc then it would not help much at all. Clients still need to talk to individual Redis nodes and Sentinel itself talks to Redis nodes.

[badboy]

@timoc then it would not help much at all. Clients still need to talk to individual Redis nodes and Sentinel itself talks to Redis nodes.

[timoc]

Understood, but in the scenario i envisage, each encrypted Redis node (and endpoint if not a local client) is running a Redis sentinel. Then the Redis sentinel manages the complexity of the transport layer security between encrypted hosts using key based authentication.

From the docs:

"Redis Sentinel is a monitoring solution for Redis instances that handles automatic failover of Redis masters and service discovery (who is the current master for a given group of instances?). Since Sentinel is both responsible to reconfigure instances during failovers, and to provide configurations to clients connecting to Redis masters or slaves, clients require to have explicit support for Redis Sentinel."

As i understand the sentinel mechanism, a redis client first connects to a sentinel to discover address of the master, then using the master information, it re-connects to the appropriate instance.
Again from the docs:

"A Redis client supporting Sentinel can automatically discover the address of a Redis master from the master name using Redis Sentinel. So instead of a hard coded IP address and port, a client supporting Sentinel should optionally be able to take as input:

A list of ip:port pairs pointing to known Sentinel instances.
The name of the service, like "cache" or "timelines".

This is the procedure a client should follow in order to obtain the master address starting from the list of Sentinels and the service name."

So in my scenario, the sentinel can create and maintain the encrypted tunnels to the various sentinel instances and clients, advertise the localhost tunnels mapping to the remote nodes.
the equivalent of managing something like:

ssh -R 6379:localhost:6379 senintel@remoteredisserverhost

This does not encrypt the data, or any overhead in the use of a local instance, only the case where i want to use Transport layer security on an encrypted cluster.

[timoc]

Understood, but in the scenario i envisage, each encrypted Redis node (and endpoint if not a local client) is running a Redis sentinel. Then the Redis sentinel manages the complexity of the transport layer security between encrypted hosts using key based authentication.

From the docs:

"Redis Sentinel is a monitoring solution for Redis instances that handles automatic failover of Redis masters and service discovery (who is the current master for a given group of instances?). Since Sentinel is both responsible to reconfigure instances during failovers, and to provide configurations to clients connecting to Redis masters or slaves, clients require to have explicit support for Redis Sentinel."

As i understand the sentinel mechanism, a redis client first connects to a sentinel to discover address of the master, then using the master information, it re-connects to the appropriate instance.
Again from the docs:

"A Redis client supporting Sentinel can automatically discover the address of a Redis master from the master name using Redis Sentinel. So instead of a hard coded IP address and port, a client supporting Sentinel should optionally be able to take as input:

A list of ip:port pairs pointing to known Sentinel instances.
The name of the service, like "cache" or "timelines".

This is the procedure a client should follow in order to obtain the master address starting from the list of Sentinels and the service name."

So in my scenario, the sentinel can create and maintain the encrypted tunnels to the various sentinel instances and clients, advertise the localhost tunnels mapping to the remote nodes.
the equivalent of managing something like:

ssh -R 6379:localhost:6379 senintel@remoteredisserverhost

This does not encrypt the data, or any overhead in the use of a local instance, only the case where i want to use Transport layer security on an encrypted cluster.

[tarcieri]

@timoc we don't use Sentinel nor want to: we already have shared infrastructure that accomplishes the same thing.

I think all parts of the Redis ecosystem should support SSL, rather than making you opt into Sentinel to be able to take advantage of it.

[tarcieri]

@timoc we don't use Sentinel nor want to: we already have shared infrastructure that accomplishes the same thing.

I think all parts of the Redis ecosystem should support SSL, rather than making you opt into Sentinel to be able to take advantage of it.

[swaj]

@bbroerman30 Thank you for all your work so far. For us, TLS/SSL is essential. One thing I wanted to bring up was OpenSSL engine support. Do you think it would be possible to add this, if it's not already present? Basically, we use hardware security modules that can expose themselves to OpenSSL through a custom engine. Would it be possible to specify the engine to use in the redis configuration file?

[swaj]

@bbroerman30 Thank you for all your work so far. For us, TLS/SSL is essential. One thing I wanted to bring up was OpenSSL engine support. Do you think it would be possible to add this, if it's not already present? Basically, we use hardware security modules that can expose themselves to OpenSSL through a custom engine. Would it be possible to specify the engine to use in the redis configuration file?

[tarcieri]

@swaj none of that is even relevant until #2402 is merged

[tarcieri]

@swaj none of that is even relevant until #2402 is merged

[swaj]

@tarcieri That exact merge is where I'm asking for the code to be placed. If @bbroerman30 doesn't have the time or desire to add it himself, I'll happily contribute the necessary code.

[swaj]

@tarcieri That exact merge is where I'm asking for the code to be placed. If @bbroerman30 doesn't have the time or desire to add it himself, I'll happily contribute the necessary code.

[bbroerman30]

I probably won't have time for a few months due to work... I can try to research it then. Can you point me to some relevant documentation?
Thanks!

Sent from my T-Mobile 4G LTE Device
-------- Original message --------From: Scott Anderson notifications@github.com Date: 4/22/16 5:08 PM (GMT-05:00) To: antirez/redis redis@noreply.github.com Cc: Brad Broerman bbroerman@bbroerman.net, Mention mention@noreply.github.com Subject: Re: [antirez/redis] Redis SSL support (#2178)
@tarcieri That exact merge is where I'm asking for the code to be placed. If @bbroerman30 doesn't have the time or desire to add it himself, I'll happily contribute the necessary code.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[bbroerman30]

I probably won't have time for a few months due to work... I can try to research it then. Can you point me to some relevant documentation?
Thanks!

Sent from my T-Mobile 4G LTE Device
-------- Original message --------From: Scott Anderson notifications@github.com Date: 4/22/16 5:08 PM (GMT-05:00) To: antirez/redis redis@noreply.github.com Cc: Brad Broerman bbroerman@bbroerman.net, Mention mention@noreply.github.com Subject: Re: [antirez/redis] Redis SSL support (#2178)
@tarcieri That exact merge is where I'm asking for the code to be placed. If @bbroerman30 doesn't have the time or desire to add it himself, I'll happily contribute the necessary code.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[swaj]

@bbroerman30 You'll want ENGINE_set_default. There's good documentation for it here:

https://www.openssl.org/docs/manmaster/crypto/engine.html

Here's an example of how Node.js does the same thing:

https://github.com/nodejs/node/blob/master/src/node_crypto.cc#L5742

[swaj]

@bbroerman30 You'll want ENGINE_set_default. There's good documentation for it here:

https://www.openssl.org/docs/manmaster/crypto/engine.html

Here's an example of how Node.js does the same thing:

https://github.com/nodejs/node/blob/master/src/node_crypto.cc#L5742

[MikesAracade]

antirez, when can this SSL patch be merged it? Like many who initially look at Redis, we need security built into the software, not just an after thought. Please consider landing this work. You might be surprised by the uptick in community adoption once it's a built in feature.

[MikesAracade]

antirez, when can this SSL patch be merged it? Like many who initially look at Redis, we need security built into the software, not just an after thought. Please consider landing this work. You might be surprised by the uptick in community adoption once it's a built in feature.

[chester89]

Something tells me that SSL support in open-source Redis will lower the
value of hosting solutions, like Redis Labs and Azure cache.
Correct me if I'm wrong.

2016-08-08 20:10 GMT+03:00 MikesAracade notifications@github.com:

antirez, when can this SSL patch be merged it? Like many who initially
look at Redis, we need security built into the software, not just an after
thought. Please consider landing this work. You might be surprised by the
uptick in community adoption once it's a built in feature.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2178 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALnfJkv4LgFRzwv4BiWkTizNAj-DPUFks5qd2MggaJpZM4DCryh
.

Yours faithfully,
Gleb

[chester89]

Something tells me that SSL support in open-source Redis will lower the
value of hosting solutions, like Redis Labs and Azure cache.
Correct me if I'm wrong.

2016-08-08 20:10 GMT+03:00 MikesAracade notifications@github.com:

antirez, when can this SSL patch be merged it? Like many who initially
look at Redis, we need security built into the software, not just an after
thought. Please consider landing this work. You might be surprised by the
uptick in community adoption once it's a built in feature.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2178 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALnfJkv4LgFRzwv4BiWkTizNAj-DPUFks5qd2MggaJpZM4DCryh
.

Yours faithfully,
Gleb

[MikesAracade]

So what?

[MikesAracade]

So what?

[chester89]

It may mean that not going forward with SSL support is no longer merely a
techical matter, it's a business matter.

2016-08-09 18:59 GMT+03:00 MikesAracade notifications@github.com:

So what?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2178 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALnfP-06YLyq-b5t2bUNoPr8qiD2-ALks5qeKPsgaJpZM4DCryh
.

Yours faithfully,
Gleb

[chester89]

It may mean that not going forward with SSL support is no longer merely a
techical matter, it's a business matter.

2016-08-09 18:59 GMT+03:00 MikesAracade notifications@github.com:

So what?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2178 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALnfP-06YLyq-b5t2bUNoPr8qiD2-ALks5qeKPsgaJpZM4DCryh
.

Yours faithfully,
Gleb

[bbroerman30]

I have versions with SSL support in my own repos. They are a little out of date (I last updated them and brought them current in December) but you are free to use them. I will be updating them again with the latest stable release code around Christmas, when I have vacation again.

[bbroerman30]

I have versions with SSL support in my own repos. They are a little out of date (I last updated them and brought them current in December) but you are free to use them. I will be updating them again with the latest stable release code around Christmas, when I have vacation again.

[kvlou]

@chester89 its a security matter.

[kvlou]

@chester89 its a security matter.

[chester89]

That's great news @bbroerman30. I will try and make Python client work with
SSL by then. Should be too hard

2016-08-09 19:27 GMT+03:00 Brad Broerman notifications@github.com:

I have versions with SSL support in my own repos. They are a little out of
date (I last updated them and brought them current in December) but you are
free to use them. I will be updating them again with the latest stable
release code around Christmas, when I have vacation again.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2178 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALnfCDFzsQi3_5d6RKj-0-BC4FFnRWuks5qeKpbgaJpZM4DCryh
.

Yours faithfully,
Gleb

[chester89]

That's great news @bbroerman30. I will try and make Python client work with
SSL by then. Should be too hard

2016-08-09 19:27 GMT+03:00 Brad Broerman notifications@github.com:

I have versions with SSL support in my own repos. They are a little out of
date (I last updated them and brought them current in December) but you are
free to use them. I will be updating them again with the latest stable
release code around Christmas, when I have vacation again.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2178 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALnfCDFzsQi3_5d6RKj-0-BC4FFnRWuks5qeKpbgaJpZM4DCryh
.

Yours faithfully,
Gleb

[chester89]

@kvlou for users of Redis - yes, sure. I meant absense of SSL support in
open-source Redis version is a business decision for hosting and cloud
providers.

2016-08-09 19:29 GMT+03:00 Gleb Chermennov thebitterend77@gmail.com:

That's great news @bbroerman30. I will try and make Python client work
with SSL by then. Should be too hard

2016-08-09 19:27 GMT+03:00 Brad Broerman notifications@github.com:

I have versions with SSL support in my own repos. They are a little out
of date (I last updated them and brought them current in December) but you
are free to use them. I will be updating them again with the latest stable
release code around Christmas, when I have vacation again.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2178 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALnfCDFzsQi3_5d6RKj-0-BC4FFnRWuks5qeKpbgaJpZM4DCryh
.

Yours faithfully,
Gleb

Yours faithfully,
Gleb

[chester89]

@kvlou for users of Redis - yes, sure. I meant absense of SSL support in
open-source Redis version is a business decision for hosting and cloud
providers.

2016-08-09 19:29 GMT+03:00 Gleb Chermennov thebitterend77@gmail.com:

That's great news @bbroerman30. I will try and make Python client work
with SSL by then. Should be too hard

2016-08-09 19:27 GMT+03:00 Brad Broerman notifications@github.com:

I have versions with SSL support in my own repos. They are a little out
of date (I last updated them and brought them current in December) but you
are free to use them. I will be updating them again with the latest stable
release code around Christmas, when I have vacation again.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2178 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALnfCDFzsQi3_5d6RKj-0-BC4FFnRWuks5qeKpbgaJpZM4DCryh
.

Yours faithfully,
Gleb

Yours faithfully,
Gleb

[hgmnz]

Something tells me that SSL support in open-source Redis will lower the
value of hosting solutions, like Redis Labs and Azure cache.

I'd much rather we all have a standard way to do SSL rather than hacking up an stunnel solution which works differently across providers, or worse forking redis to add support thus drifting away from mainline, with all the risk associated with that. The way it is now, everyone's doing it differently so we're essentially fracturing the community as a result. If it were official, client libraries can follow suit and have a cohesive standard way to do it.

[hgmnz]

Something tells me that SSL support in open-source Redis will lower the
value of hosting solutions, like Redis Labs and Azure cache.

I'd much rather we all have a standard way to do SSL rather than hacking up an stunnel solution which works differently across providers, or worse forking redis to add support thus drifting away from mainline, with all the risk associated with that. The way it is now, everyone's doing it differently so we're essentially fracturing the community as a result. If it were official, client libraries can follow suit and have a cohesive standard way to do it.

[williamsjj]

I agree. TLS support is long overdue.

[williamsjj]

I agree. TLS support is long overdue.

[tarcieri]

@hgmnz there's already a way forward for clients: they should implement SSL/TLS natively, and accept rediss:// URLs:

https://www.iana.org/assignments/uri-schemes/prov/rediss

I recently added native SSL/TLS support to redis-rb. Several other Redis client libraries already support it as well.

[tarcieri]

@hgmnz there's already a way forward for clients: they should implement SSL/TLS natively, and accept rediss:// URLs:

https://www.iana.org/assignments/uri-schemes/prov/rediss

I recently added native SSL/TLS support to redis-rb. Several other Redis client libraries already support it as well.

[hgmnz]

@tarcieri ah! Thanks for that!

[hgmnz]

@tarcieri ah! Thanks for that!

[itamarhaber]

Dear Gleb,

Despite the nice conspirational ring that your theory has, it is entirely
wrong :)

On Aug 9, 2016 5:55 PM, "Gleb Chermennov" notifications@github.com wrote:

Something tells me that SSL support in open-source Redis will lower the
value of hosting solutions, like Redis Labs and Azure cache.
Correct me if I'm wrong.

2016-08-08 20:10 GMT+03:00 MikesAracade notifications@github.com:

antirez, when can this SSL patch be merged it? Like many who initially
look at Redis, we need security built into the software, not just an
after
thought. Please consider landing this work. You might be surprised by the
uptick in community adoption once it's a built in feature.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2178 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AALnfJkv4LgFRzwv4BiWkTizNAj-DPUFks5qd2MggaJpZM4DCryh>
.

Yours faithfully,
Gleb

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2178 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFx1_N3NY5mVMpQUi2y-5lkA1ucA-Yd9ks5qeJT0gaJpZM4DCryh
.

[itamarhaber]

Dear Gleb,

Despite the nice conspirational ring that your theory has, it is entirely
wrong :)

On Aug 9, 2016 5:55 PM, "Gleb Chermennov" notifications@github.com wrote:

Something tells me that SSL support in open-source Redis will lower the
value of hosting solutions, like Redis Labs and Azure cache.
Correct me if I'm wrong.

2016-08-08 20:10 GMT+03:00 MikesAracade notifications@github.com:

antirez, when can this SSL patch be merged it? Like many who initially
look at Redis, we need security built into the software, not just an
after
thought. Please consider landing this work. You might be surprised by the
uptick in community adoption once it's a built in feature.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2178 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AALnfJkv4LgFRzwv4BiWkTizNAj-DPUFks5qd2MggaJpZM4DCryh>
.

Yours faithfully,
Gleb

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2178 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFx1_N3NY5mVMpQUi2y-5lkA1ucA-Yd9ks5qeJT0gaJpZM4DCryh
.

[chester89]

Ok, I'm more than glad to hear other theories. That's my view

2016-08-10 2:16 GMT+03:00 Itamar Haber notifications@github.com:

Dear Gleb,

Despite the nice conspirational ring that your theory has, it is entirely
wrong :)

On Aug 9, 2016 5:55 PM, "Gleb Chermennov" notifications@github.com
wrote:

Something tells me that SSL support in open-source Redis will lower the
value of hosting solutions, like Redis Labs and Azure cache.
Correct me if I'm wrong.

2016-08-08 20:10 GMT+03:00 MikesAracade notifications@github.com:

antirez, when can this SSL patch be merged it? Like many who initially
look at Redis, we need security built into the software, not just an
after
thought. Please consider landing this work. You might be surprised by
the
uptick in community adoption once it's a built in feature.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2178 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AALnfJkv4LgFRzwv4BiWkTizNAj-DPUFks5qd2MggaJpZM4DCryh>
.

Yours faithfully,
Gleb

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2178 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFx1_N3NY5mVMpQUi2y-
5lkA1ucA-Yd9ks5qeJT0gaJpZM4DCryh>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2178 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALnfNzMZ_J44GPskgoFCL7462yPQdNEks5qeQpYgaJpZM4DCryh
.

Yours faithfully,
Gleb

[chester89]

Ok, I'm more than glad to hear other theories. That's my view

2016-08-10 2:16 GMT+03:00 Itamar Haber notifications@github.com:

Dear Gleb,

Despite the nice conspirational ring that your theory has, it is entirely
wrong :)

On Aug 9, 2016 5:55 PM, "Gleb Chermennov" notifications@github.com
wrote:

Something tells me that SSL support in open-source Redis will lower the
value of hosting solutions, like Redis Labs and Azure cache.
Correct me if I'm wrong.

2016-08-08 20:10 GMT+03:00 MikesAracade notifications@github.com:

antirez, when can this SSL patch be merged it? Like many who initially
look at Redis, we need security built into the software, not just an
after
thought. Please consider landing this work. You might be surprised by
the
uptick in community adoption once it's a built in feature.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2178 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AALnfJkv4LgFRzwv4BiWkTizNAj-DPUFks5qd2MggaJpZM4DCryh>
.

Yours faithfully,
Gleb

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2178 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFx1_N3NY5mVMpQUi2y-
5lkA1ucA-Yd9ks5qeJT0gaJpZM4DCryh>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2178 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALnfNzMZ_J44GPskgoFCL7462yPQdNEks5qeQpYgaJpZM4DCryh
.

Yours faithfully,
Gleb

[itamarhaber]

I haven't any theories, but here's my view:

• All decisions concerning Redis' scope and direction are made by its
  creator and developer, and this is no different in that respect
• Since the dawn of Redis, SSL has been a hot potato
• After RDD14, its status was changed from "Wont-Fix"

I don't know about other providers, but I know that for us at Redis Labs
having SSL in Redis would be great: it means less propitiatory
technological debt, less moving pieces to take care of and, most
importantly, supported as a standard by most clients (right now only a
handful do it, others use stunnel). We were the first provider to offer it,
both to satisfy our customers' requirements but also to pave the way to its
standardization. In fact, I believe that native SSL would only serve to
increase the providers' business from that segment because of the demand it
would create.

Regardless my provider-oriented perspective, I also know Salvatore and
based on that acquaintance I find it impossible to think he'd be a part of
such sinister ploys.

On Wed, Aug 10, 2016 at 9:09 AM, Gleb Chermennov notifications@github.com
wrote:

Ok, I'm more than glad to hear other theories. That's my view

2016-08-10 2:16 GMT+03:00 Itamar Haber notifications@github.com:

Dear Gleb,

Despite the nice conspirational ring that your theory has, it is entirely
wrong :)

On Aug 9, 2016 5:55 PM, "Gleb Chermennov" notifications@github.com
wrote:

Something tells me that SSL support in open-source Redis will lower the
value of hosting solutions, like Redis Labs and Azure cache.
Correct me if I'm wrong.

2016-08-08 20:10 GMT+03:00 MikesAracade notifications@github.com:

antirez, when can this SSL patch be merged it? Like many who
initially
look at Redis, we need security built into the software, not just an
after
thought. Please consider landing this work. You might be surprised by
the
uptick in community adoption once it's a built in feature.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2178 (comment)
,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AALnfJkv4LgFRzwv4BiWkTizNAj-DPUFks5qd2MggaJpZM4DCryh>
.

Yours faithfully,
Gleb

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2178 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-
auth/AFx1_N3NY5mVMpQUi2y-
5lkA1ucA-Yd9ks5qeJT0gaJpZM4DCryh>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2178 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AALnfNzMZ_
J44GPskgoFCL7462yPQdNEks5qeQpYgaJpZM4DCryh>

.

Yours faithfully,
Gleb

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2178 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFx1_IWVRxbQdqKVB5CuDEkMLgXXt_wkks5qeWscgaJpZM4DCryh
.

Itamar Haber | Chief Developer Advocate
Redis Watch Newsletter http://redislabs.com/redis-watch-archive |
&&(curat||edit||janit||)
_Redis http://www.redislabs.com/_Labs http://www.redislabs.com/ ~/redis

Mobile: +972 (54) 567 9692
Email: itamar@redislabs.com
Twitter: @itamarhaber https://twitter.com/itamarhaber
Skype: itamar.haber

Blog http://redislabs.com/blog/ | Twitter
https://twitter.com/redislabs | LinkedIn
https://www.linkedin.com/company/redis-labs-inc

http://www.redislabs.com/

[itamarhaber]

I haven't any theories, but here's my view:

• All decisions concerning Redis' scope and direction are made by its
  creator and developer, and this is no different in that respect
• Since the dawn of Redis, SSL has been a hot potato
• After RDD14, its status was changed from "Wont-Fix"

I don't know about other providers, but I know that for us at Redis Labs
having SSL in Redis would be great: it means less propitiatory
technological debt, less moving pieces to take care of and, most
importantly, supported as a standard by most clients (right now only a
handful do it, others use stunnel). We were the first provider to offer it,
both to satisfy our customers' requirements but also to pave the way to its
standardization. In fact, I believe that native SSL would only serve to
increase the providers' business from that segment because of the demand it
would create.

Regardless my provider-oriented perspective, I also know Salvatore and
based on that acquaintance I find it impossible to think he'd be a part of
such sinister ploys.

On Wed, Aug 10, 2016 at 9:09 AM, Gleb Chermennov notifications@github.com
wrote:

Ok, I'm more than glad to hear other theories. That's my view

2016-08-10 2:16 GMT+03:00 Itamar Haber notifications@github.com:

Dear Gleb,

Despite the nice conspirational ring that your theory has, it is entirely
wrong :)

On Aug 9, 2016 5:55 PM, "Gleb Chermennov" notifications@github.com
wrote:

Something tells me that SSL support in open-source Redis will lower the
value of hosting solutions, like Redis Labs and Azure cache.
Correct me if I'm wrong.

2016-08-08 20:10 GMT+03:00 MikesAracade notifications@github.com:

antirez, when can this SSL patch be merged it? Like many who
initially
look at Redis, we need security built into the software, not just an
after
thought. Please consider landing this work. You might be surprised by
the
uptick in community adoption once it's a built in feature.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2178 (comment)
,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AALnfJkv4LgFRzwv4BiWkTizNAj-DPUFks5qd2MggaJpZM4DCryh>
.

Yours faithfully,
Gleb

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2178 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-
auth/AFx1_N3NY5mVMpQUi2y-
5lkA1ucA-Yd9ks5qeJT0gaJpZM4DCryh>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2178 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AALnfNzMZ_
J44GPskgoFCL7462yPQdNEks5qeQpYgaJpZM4DCryh>

.

Yours faithfully,
Gleb

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2178 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFx1_IWVRxbQdqKVB5CuDEkMLgXXt_wkks5qeWscgaJpZM4DCryh
.

Itamar Haber | Chief Developer Advocate
Redis Watch Newsletter http://redislabs.com/redis-watch-archive |
&&(curat||edit||janit||)
_Redis http://www.redislabs.com/_Labs http://www.redislabs.com/ ~/redis

Mobile: +972 (54) 567 9692
Email: itamar@redislabs.com
Twitter: @itamarhaber https://twitter.com/itamarhaber
Skype: itamar.haber

Blog http://redislabs.com/blog/ | Twitter
https://twitter.com/redislabs | LinkedIn
https://www.linkedin.com/company/redis-labs-inc

http://www.redislabs.com/

[phenomax]

What is the current status of this?

[phenomax]

What is the current status of this?

[tarcieri]

This is an abandoned effort and it seems Redis will never have native SSL support

[tarcieri]

This is an abandoned effort and it seems Redis will never have native SSL support

[madolson]

#4855

Another proposal for an SSL implementation, which is currently merged with the tip of unstable. Everything is behind a compile flag, so hopefully it will be easier to merge in without blocking other efforts?

[madolson]

#4855

Another proposal for an SSL implementation, which is currently merged with the tip of unstable. Everything is behind a compile flag, so hopefully it will be easier to merge in without blocking other efforts?