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? 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?
Thanks and Regards, Om Kale On Mon, May 7, 2018 at 1:11 PM, dormando <[email protected]> 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 <[email protected]> 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 <[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. > > > > > > > > > > -- > > > > --- > > 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. > > > > > > -- > > --- > 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.
