Re: Regarding setting up SASL with memcached server and getting a memcached client to associate with server.
On Mon, 7 May 2018, Om Kale wrote: > Okcouple 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 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 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 > wrote: > > > > On Fri, May 4, 2018 at 10:46 PM dormando > 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 >
Re: Regarding setting up SASL with memcached server and getting a memcached client to associate with server.
Okcouple 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 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 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 > 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 wor
Re: Regarding setting up SASL with memcached server and getting a memcached client to associate with server.
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 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 wrote: > > > On Fri, May 4, 2018 at 10:46 PM dormando > 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
Re: Regarding setting up SASL with memcached server and getting a memcached client to associate with server.
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 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 wrote: > > > On Fri, May 4, 2018 at 10:46 PM dormando > 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 h
Re: Regarding setting up SASL with memcached server and getting a memcached client to associate with server.
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 wrote: > > On Fri, May 4, 2018 at 10:46 PM dormando 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.
Re: Regarding setting up SASL with memcached server and getting a memcached client to associate with server.
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 wrote: > > On Fri, May 4, 2018 at 10:46 PM dormando 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.
