Hacker News Reader

Comment by kogepathic | Hacker News Reader

It's great to see a positive attitude toward security also gaining support in Government.

I just wish all software projects felt the need to be more secure [0]:

> Redis is designed to be accessed by trusted clients inside trusted environments.

> While Redis does not try to implement Access Control, it provides a tiny layer of authentication that is optionally turned on editing the redis.conf file.

> Redis does not support encryption.

This is just broken by design software development. [1] It's irresponsible in 2016/2017 to assume you have impenetrable perimeter security.

Redis' excuse is just bullshit. PostgreSQL supports authentication, SSL, and even client cert pinning.

[0] https://redis.io/topics/security

[1] http://antirez.com/news/96

Edit: Loving the downvotes by butthurt developers who have never had a security audit...

View on HN

Different projects - different requirements.

Perhaps you should assume people who are using it like this carefully weighted security against their requirements and came to the conclusion that it's a legit tradeoff.

> This is just broken by design software development.

This is just your "I know it all" mindset.

> Perhaps you should assume people who are using it like this carefully weighted security against their requirements and came to the conclusion that it's a legit tradeoff.

Perhaps. Or perhaps "well, I'll just use Redis because everyone else uses Redis." This is, in my experience, common. Most people choosing a stack aren't qualified to evaluate the security approach of their stack.

I don't really have a problem with Redis when somebody's going to actually either do their homework on securing it or are knowingly taking on additional risk. But you have to know it to do it. And vanishingly few people do. (And they don't ask, because they don't know to ask. The five-minute-demo culture has seen to that.)

It's basically impossible to use Redis accidentally in the way you're suggesting - to have absolutely no idea what you're getting into and fail to understand that it can run out of memory and doesn't provide security. Sure maybe before you've ever tried it or read anything at all, but you can't get very far without finding out.

You want Redis to support https so that people who haven't tried it and haven't read anything about it won't accidentally shoot themselves in the foot?

Even if you're right, your argument convinces me it's smarter for Redis to not implement security and say so than to add some in an effort to hide things for people who don't know what they're doing.

Do you have any evidence that the problem you're talking about actually exists wrt Redis? Do you have any evidence that vanishingly few people understand & do homework to offset the body of evidence of the growing number of people that can deal responsibly in security and that things are getting better over time?

> It's basically impossible to use Redis accidentally in the way you're suggesting - to have absolutely no idea what you're getting into and fail to understand that it can run out of memory and doesn't provide security.

It emphatically is not "basically impossible". I've worked with numerous teams where--well, we needed a key/value store, and Redis is cool, so let's use Redis. Hell, we don't even have to read the manual in the hallowed Age of Docker, just pull a container and there we go! Now we have Redis. Did we think about how it worked? Did we think about the security implications? No, because we needed a key/value store and now we have one and we can stop thinking about it now.

(This is why people pay me the medium bucks: to, eventually and usually after getting screwed and potentially harming their users who have no say in the matter, fix their mistakes.)

We have created a culture where ignorance of everything that is not your stack of choice is OK--and your dependencies are somehow not part of that stack, just your programming language and maybe its runtime. This is a bad culture, but it's what we've got and what the Thought Leaders seem to want. It falls to people who do give a shit to build firebreaks to control the damage that can be wrought by the practitioners of the culture of ignorance.

If nothing else, we owe it to the suckers who trust these people to do right by them.

Sometimes it can be safer to assume that something is completely insecure, than to assume ( incorrectly ) that it is. Not implementing any security on a product guarantees the former - outside of complete user incompetence. I would also say that guaranteeing security is beyond the scope of most projects, especially those with limited development resource ( Redis for example ).

For info: downvoted you not because of butthurt, but because I believe "just bullshit", "it's irresponsible", and "butthurt" are unworthy of a civilised debate.

> but because I believe "just bullshit", "it's irresponsible", and "butthurt" are unworthy of a civilised debate.

The main beef I have is that on an article about expanding the use of transport layer security, people are arguing against implementing transport layer security. To me this is an incredibly hypocritical stance for people to take.

You can downvote me because you disagree with the way I'm communicating my message, but I hope you don't disagree with the sentiment that we should be working to implement transport layer security everywhere and not just for protocols like HTTP.

Also saying my points are unworthy of civilised debate because of the language I use strikes me as incredibly naive. Donald Trump says nasty things, but people can and do debate him because the issues at hand are important to them and to the public at large. Refusing to engage someone because you disagree with the language they're using, which in my case is not hate speech or discriminating against a specific group of people, is dangerous to civil society.

Redis and Postgre are meant to play different roles.

If you don't like what Redis does, you're welcome not to use it.

> If you don't like what Redis does, you're welcome not to use it.

I like what Redis does, and it's also heavily used in industry. What I am saying, not incorrectly, is that their approach to security is harmful to their users. Most of whom won't know, care, or implement additional security which they should.

It's the same argument with HTTPS. Of course HTTPS is optional in a web server, but all major web servers support HTTPS, and there has been a concentrated push to have more people using SSL.

e.g. LetsEncrypt

We should be making it easier for people to deploy secure services. Redis' approach to security makes it extremely difficult for developers to deploy secure services.

I'll say it again: It's irresponsible in 2016/2017 to assume you have impenetrable perimeter security.

I don't get why it would be that way? It's built to be deployed in a DMZ on a private network and that's how 99% of users (typically professionals) use it.

The idea of a hardened perimeter around a soft squishy interior has been proven repeatedly not to work.

> I like what Redis does, and it's also heavily used in industry. What I am saying, not incorrectly, is that their approach to security is harmful to their users. Most of whom won't know, care, or implement additional security which they should.

Then a different security story within redis wouldn't save them anyway. Security is not magic fairy dust that you sprinkle on something and then hope for the best.

This isn't really true. Envision a system where all components are secured by default: TLS-encrypted connections in and out (which doesn't currently really exist unless you put in the work), a VPN for entry, individualized SSH keys (via SSSD or something) for machine access controlled via group policies and whatever directory services are up for grabs.

These are pretty commoditized parts that should be easily deployed and should be easily bolted together. And in such a universe, you do get a pretty strong security story without having to break your back.

My main beef with stuff like Redis is that in almost every case I can think of it's selected by developers. Security isn't on their radar. The systemic component parts we currently have don't value security and offload it to the literally (not pejoratively) incompetent.

> My main beef with stuff like Redis is that in almost every case I can think of it's selected by developers. Security isn't on their radar. The systemic component parts we currently have don't value security and offload it to the literally (not pejoratively) incompetent.

Yes, this is exactly the point I was trying to make.

> Redis' approach to security makes it extremely difficult for developers to deploy secure services.

TLS proxy is not extremely difficult to deploy if you really need to talk to redis that way. But you shouldn't be using redis if you do.

Authentication and encryption takes a lot of CPU, but turning security OFF for performance reasons should always be behind a configuration flag.

It's illegal to break into something, but if you leave the door wide open the insurance company might not be so willing, and in some laws it's actually legal to walk into open rooms.

I took those statements to be suggesting that you should be aware and implement your own security. What do you need the https access for, and why is it irresponsible to separate the database concerns from the security concerns?

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.

I'm not currently using Redis, but I would like to, and I've looked at it several times recently. Initially, I had nearly the same reaction as you, but now I think I interpret it differently.

I'd assume that you have to wrap any scalable or public Redis access in an API, you will never expose the DB directly, so https would only be used for dev work and for transport between the DB and the API layer. Both of those I would normally implement security around myself, and for API transport it is unlikely to matter when I have the API host and the DB host inside the same network.

I would think that removing Redis from the security equation probably makes a security audit easier and not harder, since you would configure dev access over ssh & share existing keys, reducing the number of entry/failure points. Same for the API transport, if necessary.

> 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.

> 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

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

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.

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?

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.

> It doesn't advertise any such thing.

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.

> 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.

[0] https://redis.io/topics/security

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.

fork -> add feature -> pull request

There is no reason to use redis over a non-local network as it loses its performance appeal completely. Even talking to a redis server on a different rack doesn't make a lot of sense, unless you have a total control over a network there. So encryption by default goes against its value proposition.

Reply on news.ycombinator.com