> I'm saying it's user hostile to say "We don't support security ... "
Redis doesn't say that, and you might not want to put quotes around something they didn't say.
Here is what they do say:
"Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket."
"in general, untrusted access to Redis should always be mediated by a layer implementing ACLs, validating user input, and deciding what operations to perform against the Redis instance. In general, Redis is not optimized for maximum security but for maximum performance and simplicity."
"Access to the Redis port should be denied to everybody but trusted clients in the network"
That's basically what I assumed, and this is a perfectly valid security model. Just because some other software with different design requirements supports certain connection types doesn't mean Redis needs to, you might want to re-examine your own assumptions.
I don't buy the analogy between Redis and nginx because nginx is a web server and Redis is an in-memory database.
A better analogy than any you have provided is between Redis and memcached. "The closest analog is probably to think of Redis as Memcached" http://stackoverflow.com/a/7897243/1424242
Memcached also doesn't support encryption, and only very recently basic authentication. Their wiki has language very similar to Redis:
"How do I authenticate? You don't! Well, you used to not be able to. Now you can. If your client supports it, you may use SASL authentication to connect to memcached."
"Keep in mind that you should do this only if you really need to. On a closed internal network this ends up just being added latency for new connections (if minor)."
"This [SASL authentication] does not provide encryption, but can provide authentication. Do not run this over the internet large, do use this to protect from neighbors and accidents from within large mostly trusted networks."
Relying on firewalls and port-access is a sucker's game. There are too many ways to defeat it that TLS is not susceptible to.
This is a fault of Redis. It's good software, on some axes. It's bad software on this one and they really, really should be better citizens about it. Security is a collaborative effort and punting it onto largely-ignorant users does not wash your hands of it.
Nobody is saying that your Redis host must be open to unencrypted traffic, not the Redis folks and not me. You do have plenty of options for putting TLS in front of any connections to your Redis install.
Redis is simply not a drop-in replacement for a SQL server environment, and they're trying to make that clear. Expecting it to be one is more your assumption than a fault of Redis.
SQLite doesn't implement any security for you, and it's probably the single most used database. Is that bad software, are they bad citizens too? Should memcached implement https? How about ImageMagick or OpenCV?
I'm a bit confused why you're arguing that Redis should provide automatic security for "largely ignorant users". Redis cannot be safely exposed to public access or an open network under any circumstances, not because of security, but because of memory management. It must be wrapped by a API server. If someone setting up a Redis install doesn't know that or doesn't know about security or doesn't know how to provide a proper wall around internal programs, what business do they have setting up servers at all? How will locking down Redis help someone who can't configure SSH between their API & DB, which you're going to have to do no matter what?
I think you are misreading me. I can, and do, secure Redis instances when I use them. But I am paid to make systems secure and scalable. That's my business, and I have invested extensive time and effort in being able to do so. I don't have a problem when I'm using it. But you accidentally stumble on it here:
> what business do they have setting up servers at all?
That's a very good question, isn't it? I mean, I'd say they don't. But, despite my generally full dance card, most developers who don't have any business doing that at all...do.
Security is ultimately a group effort, that means it falls to those of us who do give a shit to provide what measures we can for those who don't. We have decided that we want developers who are incompetent to pretend to competence. There are pragmatic, practical firebreaks that we must implement to prevent them from hurting other people. You know, from hurting me and you.
Adding https support to Redis would only do what you suggest -- add pretend competence, and hide real problems. It wouldn't add real security. It's better for the sake of ignorant users for Redis to advertise that it's insecure and they're on their own than it is to hide the ignorance.
You didn't answer any of my questions. What is your use case? In what situations do you need https support? Why should Redis be thought of differently than memcached or SQLite or ImageMagick or any other program intended for strictly internal use?
> It's better for the sake of ignorant users for Redis to advertise that it's insecure
It doesn't advertise any such thing. The manual people don't fucking read isn't advertisement because this is the future, a five-minute-demo is all you need, just grab it and start coding away.
In a future populated by competence, I would fully and completely agree with you that Redis does enough. We live in a bad future. Sucks, but--the priesthood of competence has responsibilities.
> In what situations do you need https support?
"I am talking over a network." It's not a complicated use case. TLS end-to-end, full-stop, is the only tenable future. It's still imperfect, but it's leagues better than unencrypted-over-the-wire, even inside of a theoretically secure ('cause it probably isn't) network perimeter.
That statement is false. I realize you feel strongly about this. I realize people sometimes don't read the manual. That doesn't mean the documentation doesn't exist. That doesn't mean Redis didn't try.
I'm sorry your view of other developers is so pessimistic, but just because some people do things without enough preparation doesn't mean the entire world needs to cater to their ignorance.
You still haven't answered my question: Why should Redis be thought of differently than memcached or SQLite or ImageMagick or any other program intended for strictly internal use?
There's a lot of software that uses HTTP connectivity for internal network features. Just because it exists and could be dangerous doesn't mean that HTTPS is the right answer.
Redis is designed for performance and not necessarily intended for a network at all. You are the one misunderstanding what Redis is even for, and you are the one failing to RTFM. You are complaining that people are ignorant of how to use Redis, but you are demonstrating your own ignorance here. Redis can't do what it's designed for if it switches to HTTPS-only connectivity.
I've upvoted you again only because you replied and engaged with me and finally attempted to answer my question, but you are being pretty uncivilized at this point, your language is out of hand and your attacks are personal. You're giving me reasons to stop listening to you. Goodbye and good luck.
> Nobody is saying that your Redis host must be open to unencrypted traffic, not the Redis folks and not me.
Sorry. I disagree. See:
Redis does not support encryption. [0]
> Redis is simply not a drop-in replacement for a SQL server environment, and they're trying to make that clear. Expecting it to be one is more your assumption than a fault of Redis.
I never meant to imply that Redis was a replacement for SQL. My analogy to PostgreSQL was misinterpreted by everyone to mean me saying "Redis should be more like PostgreSQL" when really what I meant was "PostgreSQL isn't focused on security, and yet they still manage to bundle TLS support without making users install additional application to wrap a socket"
> SQLite doesn't implement any security for you
SQLite is a file based DBMS. My point is about Redis lacking built-in transport layer security.
> Should memcached implement https?
memcached should implement transport layer security.
> How about ImageMagick or OpenCV?
To my knowledge these are mostly local services, although granted my experience is limited. My point to Redis was about transport layer security. If the services don't listen on any network interface, then I don't see the need to implement transport layer security.
You may still want to implement filesystem encryption to protect data at rest.
Redis doesn't support encryption, that's true. But there is literally nothing stopping you from wrapping it's use using an encrypted connection & protecting your host. Nobody is saying your host must be open to unencrypted traffic.
> To my knowledge these are mostly local services
That's a good term for it. Redis is a "mostly local service", that's exactly what their documentation is saying. Just because it listens on a network interface doesn't mean it's intended to be publicly exposed to the internet. That's why they state explicitly that Redis is not intended to be publicly exposed to the internet.
There is a lot of other software running on your computer that makes the same assumption and uses the network stack to communicate with other processes but is not intended for exposure to the internet. Redis isn't doing anything different. Go ahead and run netstat and take note of how many running services have a foreign address listed, and how many do not, of how many are using https and how many aren't.
The funny thing here is I completely agree with the premise of the TLA - I agree that we should be using HTTPS everywhere. But "everywhere" means communication over the internet, and host to host communication inside of complex networks. "Everywhere" in this context does not mean interprocess communication on my computer. Redis is designed to allow interprocess usage, and restricting it's interface to HTTPS would actively harm Redis' design goals and prevent some people from using it they way they want. PostgreSQL is not designed for that kind of usage, it is solving different problems than Redis is.
Even were I to agree with your idea that Redis is designed to be a local service, despite just about everyone using it beyond toy-problem status sticking it on a dedicated caching machine: listen unencrypted on a socket, listen encrypted on a port. Done and done.
I didn't intend for your other comment to get flagged, but since it happened -- I hear you, this is a decent point. Look, I'm not defending what Redis or anyone else is doing, I'm simply saying I understand why, I don't think it's really a super crazy choice, but I understand and agree that it is more dangerous for people that don't read the manual. There are more things they could do to help first-timers be aware of their security. I would imagine that replacing port connections with socket connection would be a pretty big step backwards in terms of ease of use, so I can imagine it'd be hard to convince them to go that way.
Redis doesn't say that, and you might not want to put quotes around something they didn't say.
Here is what they do say:
"Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket."
"in general, untrusted access to Redis should always be mediated by a layer implementing ACLs, validating user input, and deciding what operations to perform against the Redis instance. In general, Redis is not optimized for maximum security but for maximum performance and simplicity."
"Access to the Redis port should be denied to everybody but trusted clients in the network"
https://redis.io/topics/security
That's basically what I assumed, and this is a perfectly valid security model. Just because some other software with different design requirements supports certain connection types doesn't mean Redis needs to, you might want to re-examine your own assumptions.
I don't buy the analogy between Redis and nginx because nginx is a web server and Redis is an in-memory database.
A better analogy than any you have provided is between Redis and memcached. "The closest analog is probably to think of Redis as Memcached" http://stackoverflow.com/a/7897243/1424242
Memcached also doesn't support encryption, and only very recently basic authentication. Their wiki has language very similar to Redis:
"How do I authenticate? You don't! Well, you used to not be able to. Now you can. If your client supports it, you may use SASL authentication to connect to memcached."
"Keep in mind that you should do this only if you really need to. On a closed internal network this ends up just being added latency for new connections (if minor)."
https://github.com/memcached/memcached/wiki/ProgrammingFAQ#h...
"This [SASL authentication] does not provide encryption, but can provide authentication. Do not run this over the internet large, do use this to protect from neighbors and accidents from within large mostly trusted networks."
https://github.com/memcached/memcached/wiki/SASLHowto