Re: how to tell client to use ssf=256 instead of ssf=128

[Philip Guenther <guenther+ldaptech@sendmail.com>]

On Mon, 8 Oct 2012, Quanah Gibson-Mount wrote:
> --On Monday, October 08, 2012 7:42 PM +0200 Tobias Hachmer <lists@kokelnet.de>
> wrote:
> > 1. 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.


> > 2. 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