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.
