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