[Date Prev][Date Next]
Re: openldap+TLS 'works', but slapd.log reports "err=13 text=TLS confidentiality required" @ slapd start
[Moderator: I believe the following questions particular to OpenLDAP were
On Fri, 22 Aug 2008, Ben Wailea, openldap-software wrote:
> On Fri, Aug 22, 2008 at 12:50 PM, Philip Guenther
> <firstname.lastname@example.org> 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:
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
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".