4 ms·

> I don't know, but it might be extra responsible of the Redis devs to suggest they shouldn't implement your security for you, and they should stick strictly to

> I don't know, but it might be extra responsible of the Redis devs to suggest they shouldn't implement your security for you, and they should stick strictly to databases. Do you still agree if I change your statement to: I don't know, but it might be extra responsible of the nginx devs to suggest they shouldn't implement your security for you, and they should stick strictly to HTTP. I would imagine you would not agree, because it's ridiculous to have a web server only supporting HTTP in 2017. This is exactly my argument about Redis. I'm not saying Redis should implement their own crypto. I'm saying it's user hostile to say "We don't support security because perimeter security is infallible and plus no one really cares about security anyway" and you should go use another utility to wrap their socket in SSL. Sure, it's not their job to be security experts, but neither are the: - PostgreSQL developers - openLDAP developers - rsync developers And yet somehow they manage to support SSL within their application. If you read reports about data breaches lately, it's usually the following pattern: - Send a phishing email to someone in the org with malware - Infect their computer - Pivot inside the network and exfiltrate the goodies In this scenario, perimeter security is utterly worthless because the attacker has gotten themselves right into your network. If you have encrypted data between services (e.g. application servers to database, application to redis) then they also have to pop the actual servers to get the data, instead of just sitting on the network and watching traffic go back and forth. People say "oh it's not a big deal, redis is just storing sessions" until someone grabs a session from the app server to the redis server, and then pops your site as an admin.

dahart 10y ago
> 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" https://redis.io/topics/security 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 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#how-do-i-authenticate 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 https://github.com/memcached/memcached/wiki/SASLHowto
- eropple 10y ago
  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.
  - dahart 10y ago
    Why? What's your use case? 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?
    - eropple 10y ago
      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.

dahart 10y ago

> 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" https://redis.io/topics/security 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 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#how-do-i-authenticate 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 https://github.com/memcached/memcached/wiki/SASLHowto

eropple 10y ago
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.
- dahart 10y ago
  Why? What's your use case? 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?
  - eropple 10y ago
    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.