From the doc ( http://www.openldap.org/doc/admin24/security.html )
----------------- security controls disallow operations when appropriate protections are not in place. For example:
security ssf=1 update_ssf=112
requires integrity protection for all operations and encryption protection, 3DES equivalent, for update operations (e.g. add, delete, modify, etc.). See slapd.conf(5) for details. -----------------
This sounds good to me, so I read the man page, added this to my slapd.conf, and restarted openldap but now I get "stronger confidentiality required for update" when making updates.....
As a test I lowed the value to 34 (security ssf=1 update_ssf=34) halted slapd and ensured I got a clean restart. Updates still fail. If I lower it down to 31 it succeeds.
Initial reactions would be to blame a lack of SSL for the low ssf failure. I assure you I am connecting with -ZZ and an ldapsearch -ZZ returns results.
I have a suspicion that the problem is in part due to my lack of understanding. Here are the logs from an attempt (loglevel 256)
conn=0 fd=17 ACCEPT from IP=127.0.0.1:48533 (IP=0.0.0.0:389) conn=0 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=0 op=0 STARTTLS conn=0 op=0 RESULT oid= err=0 text= TLS: gnutls_certificate_verify_peers2 failed -49 conn=0 fd=17 TLS established tls_ssf=32 ssf=32 conn=0 op=1 BIND dn="cn=admin" method=128 conn=0 op=1 BIND dn="cn=admin" mech=SIMPLE ssf=0 conn=0 op=1 RESULT tag=97 err=0 text= conn=0 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=0 op=2 PASSMOD id="uid=test,ou=People,dc=testldap,dc=iwu,dc=edu" new conn=0 op=2 RESULT oid= err=13 text=stronger confidentiality required for update conn=0 op=3 UNBIND conn=0 fd=17 closed
Where I think I am getting screwed up is at either tls_ssf=32 or mech=SIMPLE ssf=0
The tls_ssf seems very low to me. gnutls is perhaps not at the top of everyone's SSL list, but my reading of the doc is that it promises TLS1.0 and SSL3.0 without SSL2.0 ( http://www.gnu.org/software/gnutls/ ) and that "SSF greater than one (>1) roughly correlates to the effective encryption key length." ( http://www.openldap.org/doc/admin24/security.html ) I would not expect something that refuses SSL2 support to select a 32 bit cipher....
The ssf=0 for simple sasl auth makes perfect sense, I am trying a simple bind. A few vendor apps I have on hand wont do more than a simple bind so that is my low water mark as it were.
In an ideal world I would like security update_ssf=128 simple_bind=112 to be working (force 3DES or better for a bind, for AES or better for an update), but I will settle for what must I do to make the documented example work for me?
Pat Ubuntu 8.04 OpenLDAP 2.4.7 (installed from repo, linked against gnutls)
--On June 12, 2008 5:01:28 PM -0500 Pat Riehecky prieheck@iwu.edu wrote:
From the doc ( http://www.openldap.org/doc/admin24/security.html )
security controls disallow operations when appropriate protections are not in place. For example:
security ssf=1 update_ssf=112
In an ideal world I would like security update_ssf=128 simple_bind=112 to be working (force 3DES or better for a bind, for AES or better for an update), but I will settle for what must I do to make the documented example work for me?
Build your own OpenLDAP linked against OpenSSL, and use a strong key for generating the cert used by OpenLDAP.
I also suggest searching the OpenLDAP-devel archives as to why using GnuTLS is considered harmful.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Thu, 2008-06-12 at 16:49 -0700, Quanah Gibson-Mount wrote:
--On June 12, 2008 5:01:28 PM -0500 Pat Riehecky prieheck@iwu.edu wrote:
From the doc ( http://www.openldap.org/doc/admin24/security.html )
security controls disallow operations when appropriate protections are not in place. For example:
security ssf=1 update_ssf=112
In an ideal world I would like security update_ssf=128 simple_bind=112 to be working (force 3DES or better for a bind, for AES or better for an update), but I will settle for what must I do to make the documented example work for me?
Build your own OpenLDAP linked against OpenSSL, and use a strong key for generating the cert used by OpenLDAP.
I also suggest searching the OpenLDAP-devel archives as to why using GnuTLS is considered harmful.
After a rebuild with openssl everything works exactly as expected,
Thanks for the info, I would not have expected that fix, but there it was!
Pat
Pat Riehecky wrote:
TLS: gnutls_certificate_verify_peers2 failed -49
1. Don't use gnutls. 2. It seems certificate verification wasn't successful.
This smells like you're working Debian Linux. So before you creating your own OpenLDAP build linked against OpenSSL make sure to update your Debian package of OpenSSL and regenerate all keys you might have generated before with Debian's OpenSSL package.
Ciao, Michael.
openldap-software@openldap.org