Hi Dormando and Trond, I think I will first try Dormando's suggestion of stunnel before delving into changing the memcached code itself. I haven't read much about stunnel, so will need to look into it in some detail. Again, thanks a lot for the support. It would have been very good if I could have used sasl (using libsasl2) directly but because of the GPLV3 license requirements that is a problem. I will keep you updated with my progress.
Thanks and Regards, Om Kale On Sat, May 5, 2018 at 4:53 PM, dormando <[email protected]> wrote: > > On Fri, May 4, 2018 at 10:46 PM dormando <[email protected]> wrote: > > > > The closest would be SCRAM-SHA-256/512 mechanism, but the RFC for > that states "in combination with TLS" up front, and I'd be wary of using it > > over the internet as well. > > > > > > If we ignore TLS for a second and just look at SCRAM it is fairly easy > to implement a minimalistic support for those mechanisms within SASL. There > is > > however one huge problem by using them in memcached without doing major > refactoring in the SASL support in memcached. By design SCRAM use a hashing > > function with an iteration count, which should be set high enough to > burn enough CPU on both the client and the server to make brute force > attacks > > "impossible" (the RFC states that for SCRAM-SHA1 it should be _at least > 4096_). Given that the memcached runs the SASL operations in the _front end > > threads_, it would block all the clients bound to that thread every time > someone tries to authenticate. If there is clients connecting all the time > one > > could end up with all worker threads running PBKDF2 hashing and all > other operations timing out ;) > > > > In order to add support for SCRAM you would have to move the hashing > over to a separate thread, and there is not an infrastructure for such > thing in the > > current memcached implementation so it would be a lot of work ;) > > > > There are actually mechanisms for passing connections to other threads in > the code now :) It's used in a few places. It's not incredibly fast but > connection rates typically aren't high enough to bother it. You'd still > burn out your CPU though... > > but, it's moot. if you don't trust your network you can't just use SASL. > :/ > > > Dormandos suggestion with stunnel (or ipsec) sounds like the least > amount of work, but if you _really_ don't want that (or you for some reason > really > > want to implement something yourself) you could look into changing > memcached to use libevents bufferevents instead of the "basic" form it use > today, and > > then add support for using the SSL level on top of bufferevents. I > haven't tested this so I have no idea of the overhead of this and how it > would affect > > the overall performance. Unless all your clients want to use SSL you > probably want a dedicated port and thread pool serving these connections. > It all > > depends on the performance requirements you've got... > > I'm more concerned about the poor person ending up stuck with a fork after > weeks of work.. it's not exactly a straightforward change. I do intend to > add TLS support this year. Would help if someone sponsored the work though > :P > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
