The problem with libsasl2 was regarding license. Also, I am unsure if libsasl2 will give me an ability to perform some sort of certificate based authentication. One more question I had was, would the use of stunnel need any code change with memached codebase?
Thanks and Regards, Om Kale On Mon, May 7, 2018 at 12:40 PM, dormando <dorma...@rydia.net> wrote: > Hey, > > Just to be clear: I'm completely positive you can make this work with just > the libsasl2 that comes with openwrt, you don't need to rebuild it. the > problem is you can't use sasl over an untrusted network: SASL is supposed > to be used underneath TLS or a trusted network. > > Either way, try stunnel. that might just make your life easier in both > directions, it's fairly simple. > > On Mon, 7 May 2018, Om Kale wrote: > > > 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 <dorma...@rydia.net> wrote: > > > On Fri, May 4, 2018 at 10:46 PM dormando <dorma...@rydia.net> > 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 memcached+unsubscr...@googlegroups.com. > > 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 memcached+unsubscr...@googlegroups.com. > > 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 memcached+unsubscr...@googlegroups.com. > 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
