--On Friday, November 17, 2017 12:53 PM +1000 William Brown wibrown@redhat.com wrote:
Hi William,
Hey mate,
Just want to point out there are some security risks with ssf settings. I have documented these here:
https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.html
This is a flaw in the ldap protocol and can never be resolved without breaking the standard. The issue is that by the time the ssf check is done, you have already cleartexted sensitive material.
I think what you mean is: There is no way with startTLS to prevent possible leakage of credentials when using simple binds. ;) Your blog certainly covers this concept well, but just wanted to be very clear on what the actual issue is. ;) I've been rather unhappy about this for a long time as well, and have had a discussion going on the openldap-devel list about LDAPv4 and breaking backwards compatibility to fix this protocol bug.
Another note -- The reason GSSAPI shows up as an SSF of 56 is because it has been hard coded that way in cyrus-sasl. Starting with cyrus-sasl version 2.1.27, which is near release, the actual SASL SSF is finally passed back into the caller. It may be worthwhile noting this in your blog post. ;)
Warm regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Thu, 2017-11-16 at 21:25 -0800, Quanah Gibson-Mount wrote:
--On Friday, November 17, 2017 12:53 PM +1000 William Brown wibrown@redhat.com wrote:
Hi William,
Hey mate,
Just want to point out there are some security risks with ssf settings. I have documented these here:
https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.ht ml
This is a flaw in the ldap protocol and can never be resolved without breaking the standard. The issue is that by the time the ssf check is done, you have already cleartexted sensitive material.
I think what you mean is: There is no way with startTLS to prevent possible leakage of credentials when using simple binds. ;) Your blog certainly covers this concept well, but just wanted to be very clear on what the actual issue is. ;) I've been rather unhappy about this for a long time as well, and have had a discussion going on the openldap-devel list about LDAPv4 and breaking backwards compatibility to fix this protocol bug.
Absolutely. I think it's just better to say look, expect leakage. Do it right, once, and guarantee your behaviours. It's not just simple bind though,
An example here though, is because of how minssf works, we have to accept anonymous binds on ssf=0, because we expect starttls next - even then, you can leak things like "search mail=secret@secret". If they don't want to leak phone numbers, mail etc. So we have a dataleak in the form of the query, before the ssf check can reject our request.
Sure, we aren't leaking entries, but we shouldn't leak *anything* if we are in this kind of environment,
Again coming back to LDAPS is the only way to really guarantee this connection is truly encrypted from the first byte to the last :)
Another note -- The reason GSSAPI shows up as an SSF of 56 is because it has been hard coded that way in cyrus-sasl. Starting with cyrus- sasl version 2.1.27, which is near release, the actual SASL SSF is finally passed back into the caller. It may be worthwhile noting this in your blog post. ;)
Yeah, the krb devs told me about this change recently, I should go and update this :) I've just been busy lately :)
Thanks mate,
Warm regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
William Brown wibrown@redhat.com schrieb am 17.11.2017 um 06:31 in Nachricht
1510896691.4395.140.camel@redhat.com:
On Thu, 2017-11-16 at 21:25 -0800, Quanah Gibson-Mount wrote:
--On Friday, November 17, 2017 12:53 PM +1000 William Brown wibrown@redhat.com wrote:
Hi William,
Hey mate,
Just want to point out there are some security risks with ssf settings. I have documented these here:
https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.ht ml
This is a flaw in the ldap protocol and can never be resolved without breaking the standard. The issue is that by the time the ssf check is done, you have already cleartexted sensitive material.
I think what you mean is: There is no way with startTLS to prevent possible leakage of credentials when using simple binds. ;) Your blog certainly covers this concept well, but just wanted to be very clear on what the actual issue is. ;) I've been rather unhappy about this for a long time as well, and have had a discussion going on the openldap-devel list about LDAPv4 and breaking backwards compatibility to fix this protocol bug.
Absolutely. I think it's just better to say look, expect leakage. Do it right, once, and guarantee your behaviours. It's not just simple bind though,
An example here though, is because of how minssf works, we have to accept anonymous binds on ssf=0, because we expect starttls next - even then, you can leak things like "search mail=secret@secret". If they don't want to leak phone numbers, mail etc. So we have a dataleak in the form of the query, before the ssf check can reject our request.
Sure, we aren't leaking entries, but we shouldn't leak *anything* if we are in this kind of environment,
Hi!
BTW: Does anyone know the backgraound of SUSE Linux Enterprise Server (SLES) moving from OpenLDAP to Redhat's directory server in ist next release?
Regards, Ulrich
Again coming back to LDAPS is the only way to really guarantee this connection is truly encrypted from the first byte to the last :)
Another note -- The reason GSSAPI shows up as an SSF of 56 is because it has been hard coded that way in cyrus-sasl. Starting with cyrus- sasl version 2.1.27, which is near release, the actual SASL SSF is finally passed back into the caller. It may be worthwhile noting this in your blog post. ;)
Yeah, the krb devs told me about this change recently, I should go and update this :) I've just been busy lately :)
Thanks mate,
Warm regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
-- Sincerely,
William Brown Software Engineer Red Hat, Australia/Brisbane
openldap-technical@openldap.org
-
Quanah Gibson-Mount -
Ulrich Windl -
William Brown