[Pkg-openldap-devel] Bug#473796: Bug#473796: Bug#473796: TLS fails completely

[Steve Langasek]

On Thu, Apr 03, 2008 at 12:28:56PM -0700, Quanah Gibson-Mount wrote:
> > ok, more testing, more news:

> >>> now with the slapd 2.4.7 package (with gnutls) this seems to force
> >>> client-certs, too. a TLS query without client-cert won't work - but
> >>> commenting the 'security' line out results in working TLS and working
> >>> non-TLS queries.

> >> The default behavior when TLS is enabled is "TLSVerifyClient never";
> >> 2.4.7 did have a bug related to this, but this was resolved in the
> >> 2.4.7-5 package.

> > well it seems to me like with gnutls the 'security tls=' value controls
> > the tls reqirements, TLSVerifyClient is (more or less?) ignored. but i
> > could be missing something ofc...

> > all queries done with a server cert and without a client cert:

> > security tls=128
> > TLSVerifyClient never

> > ldapsearch		fails (TLS confidentiality required)
> > ldapsearch -ZZ		fails (stronger TLS confidentiality required)

> This will always fail as long as the keystrength of the cert in question is 
> so low.  It states quite clearly in your log:

> conn=0 fd=12 TLS established tls_ssf=32 ssf=32

> I.e., the TLS SSF is 32.  So no value > 32 will ever work.

This suggests to me that the SSF values haven't been properly normalized for
GNUtls.  Doesn't the "128" mean, roughly, a symmetric cipher with keylength
of 128?  Surely the user's "TLSCipherSuite TLS_RSA_AES_256_CBC_SHA1" should
satisfy this?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org