Hi,
I am a little confused with this. Basically I have a client connecting to the database, a DECT IP phone base station which doesn't support STARTLS and my slapd config has settings for clients to use certificates to connect.
What would be the best way to set this up so that the DECT IP client only accesses the particular place that it needs to, the AddressBook section but then other clients will need to use STARTTLS for everything else??
Currently I am looking at:
https://www.openldap.org/doc/admin24/security.html
https://www.openldap.org/doc/admin24/access-control.html
and have currently put this in my slapd.conf:
#Removed the Global? security clause
#security ssf=128
#Added generic ACL for all access to require ssf of 128
access to * by ssf=128 self write by ssf=128 anonymous auth by ssf=128 users read
#Added ACL for open access to AddressBook in Read and Search only mode
access to dn.children="ou=AddressBook,dc=domain,dc=com" by * search by * read
Is this correct or do I need to engage the "security" Global section too?
Though the documentation suggests otherwise: "For fine-grained control, SSFs may be used in access controls. See theAccess Control https://www.openldap.org/doc/admin24/access-control.htmlsection for more information."
Thanks.
Kaya
On Tue, 2017-11-14 at 20:56 +0000, Kaya Saman wrote:
Hi,
I am a little confused with this. Basically I have a client connecting to the database, a DECT IP phone base station which doesn't support STARTLS and my slapd config has settings for clients to use certificates to connect.
What would be the best way to set this up so that the DECT IP client only accesses the particular place that it needs to, the AddressBook section but then other clients will need to use STARTTLS for everything else??
Currently I am looking at:
https://www.openldap.org/doc/admin24/security.html
https://www.openldap.org/doc/admin24/access-control.html
and have currently put this in my slapd.conf:
#Removed the Global? security clause
#security ssf=128
#Added generic ACL for all access to require ssf of 128
access to * by ssf=128 self write by ssf=128 anonymous auth by ssf=128 users read
#Added ACL for open access to AddressBook in Read and Search only mode
access to dn.children="ou=AddressBook,dc=domain,dc=com" by * search by * read
Is this correct or do I need to engage the "security" Global section too?
Though the documentation suggests otherwise: "For fine-grained control, SSFs may be used in access controls. See theAccess Control https://www.openldap.org/doc/admin24/access-control.htmlsection for more information."
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 would advise that you use LDAPS with TLS instead, or provide suitable access control over your network segments to prevent these issues. Relying on SSF can allow data leaks from misconfigured clients.
Hope that helps,
William Brown wrote:
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
Nice writeup. I always considered SSF values to be naive and somewhat overrated. People expect too much when looking at these numbers - especially regarding the "strength" of cryptographic algorithms which changes over time anyway with new cryptanalysis results coming up.
Personally I always try to implement a TLS-is-must policy and prefer LDAPS (with correct protocol and ciphersuites configured) over LDAP/StartTLS to avoid this kind of pre-TLS leakage. Yes, I deliberately ignore "LDAPS is deprecated". ;-]
Furthermore some LDAP server implementation (IIRC e.g. MS AD) refuse to accept SASL/GSSAPI bind requests sent over TLS-secured channel. Which is IMO also somewhat questionable.
Ciao, Michael.
On Fri, 2017-11-17 at 08:34 +0100, Michael Ströder wrote:
William Brown wrote:
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
Nice writeup. I always considered SSF values to be naive and somewhat overrated. People expect too much when looking at these numbers - especially regarding the "strength" of cryptographic algorithms which changes over time anyway with new cryptanalysis results coming up.
Personally I always try to implement a TLS-is-must policy and prefer LDAPS (with correct protocol and ciphersuites configured) over LDAP/StartTLS to avoid this kind of pre-TLS leakage. Yes, I deliberately ignore "LDAPS is deprecated". ;-]
I agree. If only there was a standards working group that could deprecate startTLS in favour of TLS .... :)
Furthermore some LDAP server implementation (IIRC e.g. MS AD) refuse to accept SASL/GSSAPI bind requests sent over TLS-secured channel. Which is IMO also somewhat questionable.
Yes, I really agree. While a plain text port exists, data leaks are possible. We should really improve this situation, where we have TLS for all data to prevent these mistakes.
I think a big part of the issue is that GSSAPI forces the encryption layer, and can't work via an already encrypted channel. The people I know involved in this space are really resistant to changing this due to the "kerberos centric" nature of the products.
Ciao, Michael.
openldap-technical@openldap.org
-
Kaya Saman -
Michael Ströder -
William Brown