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.
