Consider making TLS support mandatory #58

New issue

Open

opened 2024-09-18 12:19:37 +02:00 by ddevault · 1 comment

ddevault commented

2024-09-18 12:19:37 +02:00

Owner

And make OpenSSL a mandatory dependency. We may also consider suitably annoying warnings if, for instance, listening on a public IP address without TLS enabled.

bitfehler commented

2024-09-25 13:45:03 +02:00

We may also consider suitably annoying warnings if, for instance, listening on a public IP address without TLS enabled.

While I wholeheartedly agree with the concept, I would like to point out that redict's configuration with regards to TLS is - in my opinion - a bit too simplistic. Consider the following:

TLS seems to incur a rather significant performance penalty (see this blog post and this issue that the post also links to)
Redict lets you only specify the address(es) to bind on globally, and then the ports to listen on for plain and/or TLS, which will all be opened on all addresses provided to the bind option (including the one for cluster communication!)

Given the potential performance impact, I think it is reasonable that one might want to use the cluster without TLS on an internal network, but expose TLS to the outside. At the very least, it might be desirable to run the cluster port without TLS on a different address?

I understand that this is all for historical reasons, and that one main goal of redict is be a drop-in replacement for redis. Is adding support for something like this, maybe by means of new config directives (while keeping the old ones working as expected) something that would be in scope for redict?

> We may also consider suitably annoying warnings if, for instance, listening on a public IP address without TLS enabled. While I wholeheartedly agree with the concept, I would like to point out that redict's configuration with regards to TLS is - in my opinion - a bit too simplistic. Consider the following: 1. TLS seems to incur a rather significant performance penalty (see [this blog post](https://docs.keydb.dev/blog/2020/09/29/blog-post/) and [this issue](https://github.com/redis/redis/issues/7595) that the post also links to) 2. Redict lets you only specify the address(es) to bind on globally, and then the ports to listen on for plain and/or TLS, which will all be opened on all addresses provided to the bind option (including the one for cluster communication!) Given the potential performance impact, I think it is reasonable that one might want to use the cluster without TLS on an internal network, but expose TLS to the outside. At the very least, it might be desirable to run the cluster port without TLS on a different address? I understand that this is all for historical reasons, and that one main goal of redict is be a drop-in replacement for redis. Is adding support for something like this, maybe by means of new config directives (while keeping the old ones working as expected) something that would be in scope for redict?