[Date Prev][Date Next]
Re: how to tell client to use ssf=256 instead of ssf=128
On Mon, 8 Oct 2012, Quanah Gibson-Mount wrote:
> --On Monday, October 08, 2012 7:42 PM +0200 Tobias Hachmer <firstname.lastname@example.org>
> > 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
> > 2. Can I influence the ssf used by client, if yes, how?
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
When OpenLDAP is built against OpenSSL, something like
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