Hello,
I'm using openldap 2.4.28 on ubuntu server and configured TLS. I want to allow write operations only when ssf=256 is used. (security update_ssf=256) Certificates were set up with openssl CA.pl.
When I connect via # ldapadd -Y EXTERNAL -ZZ -f /src/test.ldif
I get this: SASL/EXTERNAL authentication started SASL username: cn=ldapadmin,............. SASL SSF: 0 adding new entry "dc=example,dc=com" ldap_add: Confidentiality required (13) additional info: stronger confidentiality required for update
the log says: Oct 8 19:38:14 ldap slapd[2205]: conn=1003 fd=13 ACCEPT from IP=127.0.0.1:56698 (IP=0.0.0.0:389) Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=0 STARTTLS Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=0 RESULT oid= err=0 text= Oct 8 19:38:14 ldap slapd[2205]: conn=1003 fd=13 TLS established tls_ssf=128 ssf=128 Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=1 BIND dn="" method=163 Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=1 BIND authcid="cn=ldapadmin,........." authzid="cn=ldapadmin,........" Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=1 BIND dn="cn=ldapadmin,......." mech=EXTERNAL sasl_ssf=0 ssf=128 Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=1 RESULT tag=97 err=0 text= Oct 8 19:38:14 ldap slapd[2205]: connection_input: conn=1003 deferring operation: binding Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=2 ADD dn="dc=example,dc=com" Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=2 RESULT tag=105 err=13 text=stronger confidentiality required for update Oct 8 19:38:14 ldap slapd[2205]: conn=1003 op=3 UNBIND Oct 8 19:38:14 ldap slapd[2205]: conn=1003 fd=13 closed
1. Why is the client connecting with ssf=128? 2. Can I influence the ssf used by client, if yes, how? 3. Maybe a certificate issue?
Thanks in advance, Tobias Hachmer
--On Monday, October 08, 2012 7:42 PM +0200 Tobias Hachmer lists@kokelnet.de wrote:
Hello,
- Why is the client connecting with ssf=128?
Because its cert key is 128 bits.
- Can I influence the ssf used by client, if yes, how?
No.
- Maybe a certificate issue?
Yes. If you want to force 256-bit keys, then all clients need to be issued certs with 256-bit keys.
https://en.wikipedia.org/wiki/Key_size
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On Mon, 8 Oct 2012, Quanah Gibson-Mount wrote:
--On Monday, October 08, 2012 7:42 PM +0200 Tobias Hachmer lists@kokelnet.de wrote:
- Why is the client connecting with ssf=128?
Because its cert key is 128 bits.
I don't believe that to be the case. For RSA, keys generally *start* at 512 bits and go up from there, with 2048 considered a bare minimum by many now. I'm not sure what length you would therefore be referring to for a "cert key" of 128 bits.
My understanding is that the key length that the SSF is measured against is, for TLS, the symmetrical key of the TLS cipher suite. E.g., AES128-SHA has an SSF of 128, because the key for the AES cipher is 128 bits.
- Can I influence the ssf used by client, if yes, how?
No.
If my belief that it's the cipher key length that matter is correct, then configuring the TLSCipherSuite option (aka olcTLSCipherSuite) to require a cipher with 256bit key should be sufficient. Note that doing that requires *all* TLS connections to be that strong, even those that aren't doing updates, for which the original poster doesn't feel a need for such strength.
When OpenLDAP is built against OpenSSL, something like TLSCipherSuite AES256!aNULL
Check the slapd.conf(5) or slapd-config(5) manpage, plus your crypto implementation's docs for details.
(I recall that some webservers could be configured to require a higher strength cipher for particular URLs, in which case they would force another TLS handshake with the smaller set of offered ciphers if you accessed such a URL with a weaker cipher. I haven't kept up with whether that capability was effectively eliminated by the TLS renegotiation attack problems, and I don't think OpenLDAP has ever had such a feature. It would be dubious for sites using simply auth to do that, as the upgrade wouldn't protect the password anyway, but for a site using client certs, like the original poster, I suppose it could make security sense to do that...)
Philip Guenther
--On Monday, October 08, 2012 11:46 AM -0700 Philip Guenther guenther+ldaptech@sendmail.com wrote:
On Mon, 8 Oct 2012, Quanah Gibson-Mount wrote:
--On Monday, October 08, 2012 7:42 PM +0200 Tobias Hachmer lists@kokelnet.de wrote:
- Why is the client connecting with ssf=128?
Because its cert key is 128 bits.
I don't believe that to be the case. For RSA, keys generally *start* at 512 bits and go up from there, with 2048 considered a bare minimum by many now. I'm not sure what length you would therefore be referring to for a "cert key" of 128 bits.
Hm, I swear when I played with this several years ago, going from 1024 bits to 2048 bits changed my ssf from 128 to 256. But it has been a long time. ;)
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Bonsoir,
2012/10/8 Tobias Hachmer lists@kokelnet.de:
I'm using openldap 2.4.28 on ubuntu server and configured TLS. I want to allow write operations only when ssf=256 is used. (security update_ssf=256)
[...]
- Why is the client connecting with ssf=128?
That's a result of ciphersuite negociation.
- Can I influence the ssf used by client, if yes, how?
Just allow 256bits ciphersuites on the client or the server, or place 256bits ciphersuites first in the list. Try adding this to your global ldap.conf or locap .ldaprc file:
TLS_CIPHER_SUITE AES256
or
TLS_CIPHER_SUITE SECURE256
Depending on the crypto library used (OpenSSL or GNUTLS).
- Maybe a certificate issue?
No. You can do DES (56bits) or AES256 with the same certificate.
openldap-technical@openldap.org
-
Erwann Abalea -
Philip Guenther -
Quanah Gibson-Mount -
Tobias Hachmer