Hey Dormando, I have figured the stunnel approach and it works. So AUTH is figured out. Thanks for the guidance. Now. I have one more question about encryption. SASL requires binary protocol to be enabled. However, if I use binary protocol, the set encyption key function by libmemcached fails: void memcached_set_encoding_key(memcached_st <http://docs.libmemcached.org/memcached_create.html#memcached_st>* *ptr*, const char* *string*, const size_t <http://docs.libmemcached.org/types.html#size_t>* string_length*)ΒΆ <http://docs.libmemcached.org/libmemcached-1.0/memcached_set_encoding_key.html#memcached_set_encoding_key>
When I use the above with binary protocol, the value set using memcached set and received with memcached get do not match. Is there a specific reason why only binary protocol can be used for sasl auth in memcached? Thanks and Regards, Om Kale On Mon, May 7, 2018 at 5:17 PM, dormando <dorma...@rydia.net> wrote: > On Mon, 7 May 2018, Om Kale wrote: > > > Ok....couple of follow up questions on the same:1. Inorder to enable/set > up stunnel on memcached server, I need to create certificates using > openssl. How > > do I execute the openssl certificate generation on memcached server? > Also, after this how could I distribute this to client? > > There are lots of guides online about how to manage certificates; that is > beyond the scope of this mailing list. I will give you a hint though: that > you don't need to generate the certificates from any particular place. > > > 2. Additionally, when you say 'you can modify libmemcached to use > OpenSSL directly', you mean setting up the socket connections in client to > support > > SSL/TLS, corect? > > Yes. > > > > > Thanks and Regards,Om Kale > > > > > > On Mon, May 7, 2018 at 1:11 PM, dormando <dorma...@rydia.net> wrote: > > hmm. I guess so... > > > > re: stunnel, as I detailed you still have to get the client > (libmemcached) > > to talk over TLS. For the server, no change. > > > > For the client, you could prototype by having stunnel local to the > client > > and connect through that. so you have stunnel talking to stunnel. > If > > that's not something you can deploy for clients, you can modify > > libmemcached to use OpenSSL directly, which should be easier than > > modifying the server. > > > > On Mon, 7 May 2018, Om Kale wrote: > > > > > 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. > > > > > > > > > > -- > > > > --- > > 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.
