Re: openldap+TLS 'works', but slapd.log reports "err=13 text=TLS confidentiality required" @ slapd start

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

[Moderator: I believe the following questions particular to OpenLDAP were 
still unanswered]

On Fri, 22 Aug 2008, Ben Wailea, openldap-software wrote:
> On Fri, Aug 22, 2008 at 12:50 PM, Philip Guenther
> <guenther+ldapsoft@sendmail.com> wrote:
...
> >        security tls=256
> >
> > I.e., refuse to do _anything_ unless TLS is negotiated with an SSF of at
> > least 256 (i.e., 256 bit encryption cipher).  Is that *really* the
> > requirement you mean to enforce?
> 
> the goal is to always/only use TLS with an AES-256 encryption cipher.
> the hope is that that 'security' directive accomplishges that.

Sorta.  It makes LDAP requests fail if they didn't use TLS with AES-256, 
but it doesn't prevent a client from negotiating TLS with, say, AES-128.  
If you want to require AES-256, then you should set the TlsCipherSuite 
option to limit the accept ciphers also.  The exact syntax will depend on 
whether you're using OpenSSL or GNUtls and what type of key the server 
has.  See the slapd.conf(5) manpage for details.

(Interestingly, some versions of openssl support AES256, but don't have 
any way to say "accept AES256 and not AES126".  In effect, the cipher 
suite parsing can't "tell them apart".  So test your settings before 
relying on them!)


> >>       disallow tls_2_anon
> >
> > Hmm, why do you set that option?  Do you know why the default isn't to do
> > that?
> 
> the goal is to not allow any anonymous connetion/bind/etc.
>
> to the extent that 'man slapd.conf' shares
> 
>  tls_2_anon disables
>  Start TLS from forcing session to anonymous status (see
>  also tls_authc).  tls_authc disables StartTLS if
>  authenticated (see also tls_2_anon).
> 
> that seems to be the right choice.  afaict, there's no additional
> documentation on the matter.

That's not what the "disallow tls_2_anon" option does.

By default, if a client does this:
	BIND
	STARTTLS

then the STARTTLS will 'undo' the authentication, reverting it to 
anonymous.  That's good because the connection was unprotected between the 
BIND and the STARTTLS and could have been hijacked.  The option
	disallow tls_2_anon

changes it so that it _doesn't_ revert to anonymous.  That option is 
*less* secure than the default and should only be used in specific 
situations where required and the implications are understood.

However, your other settings make the change pointless, because you don't 
permit BIND before STARTTLS anyway!


> and, that description smacks of "read other side" being written on
> both sides of a postcard ...

Not at all.  The tls_2_anon says "if you do permit STARTTLS after BIND, 
then don't undo the BIND", while "tls_authc" says "don't permit STARTTLS 
after BIND at all".


Philip Guenther