4 ms·

> But... why? SSL will eventually make it into the official Redis release. "Eventually" it's 2018. It's too late. I'm especially cynical and jaded about the i

> But... why? SSL will eventually make it into the official Redis release. "Eventually" it's 2018. It's too late. I'm especially cynical and jaded about the insanity of running any plaintext protocols in 2018, why wasn't SSL/TLS implemented by now? It should have been at the top of the priority list. People who think unencrypted traffic is okay should have their competency challenged. Sure, in very limited specific deployment models you can maybe get away with it without compromising security, but actually even in the most restrictive networks it is still an open door for exploitation. It's the same kind of stupidity as Docker running as root by default... this stuff is amateur hour and these apps are mission critical enterprise tools. That's a bad recipe. In the 90s it was forgiveable, today it is not. Kudos to the guy. Maybe it'll light a fire under the official project. Or maybe the fork will pick up steam. It'll be interesting to see what happens.

decebalus1 8y ago
Redis plaintext was a conscious decision, it wasn't due to laziness, lack of knowledge or lax security policies. And Redis is not a mission-critical enterprise tool. 'Redis enterprise'[1] is, and it does have security features. Redis is a tool and does what you make of it. You shouldn't have such demands for an open source project. It explicitly states that it doesn't support that and even gives you a workaround and warns you about your deployment model. The problem here is that this change is not a fork-worthy feature. This is PR-level stuff. This discussion is not about Redis being 'amateur hour'. It may be for some people who have no idea what they're doing, but the industry managed to go around that. Also, https://github.com/antirez/redis/pull/4855 https://github.com/antirez/redis/pull/4855 ? [1] https://redislabs.com/redis-enterprise/ https://redislabs.com/redis-enterprise/
- DrJosiah 8y ago
  Redis is used as a mission critical tool by companies, whether it wants to be or not. The SSL/TLS changes I was making were going to be easy to merge in for those who were interested. And the fork wasn't just for SSL/TLS; it was for transactions, speedups, and other work that is in-process. Some of that very well may make it back upstream. I can't say; a lot of what I've already done and am planning has been rejected before. Which is why there is the fork. I need those things, Salvatore already rejected them, maybe someone else would need them too, I'll fork.
  - decebalus1 8y ago
    I have to admit, I didn't look over your code and haven't noticed it incorporated multiple ideas aside from TLS. You're correct, if the main project doesn't accept the contributions then the beauty of open-source is that you can roll your own and fork it. About the mission critical stuff I was mentioning is a pet peeve of mine. Often people don't realize that most of this stuff is 'buyer beware' and comes with no guarantees. So if a tool has a certain set of features and becomes mission critical then you can't 'demand' extra features just because it became so important. The right approach is to either support the business side of the project and upgrade or as I mentioned above, roll your own.
tptacek 8y ago
This is reductive. I don't know what the faction of major Redis deployments (by transaction volume or data size or however you want to measure) that are housed in AWS is, but I'm guessing it's north of 50%. In an AWS Redis environment, running Redis over TLS is not in the top 10 systems security concerns relative to database security. The access you need to attack Redis for lack of TLS is almost certainly gameover by itself with or without TLS. I'm not saying Redis TLS is a bad thing (honestly: I'd prioritize "not having Redis in a design" over "making sure Redis runs over TLS"), but I think in a lot of very mainstream designs, it's mostly a cosmetic security control.
- aeorgnoieang 8y ago
  > I'd prioritize "not having Redis in a design" Why?
  - odammit 8y ago
    > Why? Why?
  - tptacek 8y ago
    Not in general, just over optimizing the transport security of Redis.
    - DrJosiah 8y ago
      In one example test I ran, the SSL/TLS unwrapping daemon used 5x the CPU of Redis itself. And generally, the unwrapping daemons always used more CPU (for the reasons explained in the article). With integrated SSL, you're looking at substantially reduced CPU overhead, just from reduced interrupt handling and memcpy operations. For the examples I was running, it's like going from 2 hours of total CPU time to 50 minutes, versus 40 minutes for no SSL/TLS. Or going from 1 hour to run the test to 45 minutes, versus 35 minutes with no SSL/TLS.
DrJosiah 8y ago
I worked on adding SSL/TLS because I see it as a need, and I knew that I was losing performance with SSL/TLS unwrapping daemons. Until I finished and started benchmarking, I just didn't know how bad the performance hit was. I'm just glad that PR #4855 is going to be merged; it's better code than I wrote, and is faster. We'll see if the other stuff I'm working on causes the fork to take off; SSL/TLS won't :P

decebalus1 8y ago

Redis plaintext was a conscious decision, it wasn't due to laziness, lack of knowledge or lax security policies. And Redis is not a mission-critical enterprise tool. 'Redis enterprise'[1] is, and it does have security features. Redis is a tool and does what you make of it. You shouldn't have such demands for an open source project. It explicitly states that it doesn't support that and even gives you a workaround and warns you about your deployment model. The problem here is that this change is not a fork-worthy feature. This is PR-level stuff. This discussion is not about Redis being 'amateur hour'. It may be for some people who have no idea what they're doing, but the industry managed to go around that. Also, https://github.com/antirez/redis/pull/4855 https://github.com/antirez/redis/pull/4855 ? [1] https://redislabs.com/redis-enterprise/ https://redislabs.com/redis-enterprise/

DrJosiah 8y ago
Redis is used as a mission critical tool by companies, whether it wants to be or not. The SSL/TLS changes I was making were going to be easy to merge in for those who were interested. And the fork wasn't just for SSL/TLS; it was for transactions, speedups, and other work that is in-process. Some of that very well may make it back upstream. I can't say; a lot of what I've already done and am planning has been rejected before. Which is why there is the fork. I need those things, Salvatore already rejected them, maybe someone else would need them too, I'll fork.
- decebalus1 8y ago
  I have to admit, I didn't look over your code and haven't noticed it incorporated multiple ideas aside from TLS. You're correct, if the main project doesn't accept the contributions then the beauty of open-source is that you can roll your own and fork it. About the mission critical stuff I was mentioning is a pet peeve of mine. Often people don't realize that most of this stuff is 'buyer beware' and comes with no guarantees. So if a tool has a certain set of features and becomes mission critical then you can't 'demand' extra features just because it became so important. The right approach is to either support the business side of the project and upgrade or as I mentioned above, roll your own.

tptacek 8y ago

This is reductive. I don't know what the faction of major Redis deployments (by transaction volume or data size or however you want to measure) that are housed in AWS is, but I'm guessing it's north of 50%. In an AWS Redis environment, running Redis over TLS is not in the top 10 systems security concerns relative to database security. The access you need to attack Redis for lack of TLS is almost certainly gameover by itself with or without TLS. I'm not saying Redis TLS is a bad thing (honestly: I'd prioritize "not having Redis in a design" over "making sure Redis runs over TLS"), but I think in a lot of very mainstream designs, it's mostly a cosmetic security control.

aeorgnoieang 8y ago
> I'd prioritize "not having Redis in a design" Why?
- odammit 8y ago
  > Why? Why?
- tptacek 8y ago
  Not in general, just over optimizing the transport security of Redis.
  - DrJosiah 8y ago
    In one example test I ran, the SSL/TLS unwrapping daemon used 5x the CPU of Redis itself. And generally, the unwrapping daemons always used more CPU (for the reasons explained in the article). With integrated SSL, you're looking at substantially reduced CPU overhead, just from reduced interrupt handling and memcpy operations. For the examples I was running, it's like going from 2 hours of total CPU time to 50 minutes, versus 40 minutes for no SSL/TLS. Or going from 1 hour to run the test to 45 minutes, versus 35 minutes with no SSL/TLS.

DrJosiah 8y ago

I worked on adding SSL/TLS because I see it as a need, and I knew that I was losing performance with SSL/TLS unwrapping daemons. Until I finished and started benchmarking, I just didn't know how bad the performance hit was. I'm just glad that PR #4855 is going to be merged; it's better code than I wrote, and is faster. We'll see if the other stuff I'm working on causes the fork to take off; SSL/TLS won't :P