Re: Starttls and SSL

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

ldap@mm.st writes:
> While sniffing traffic using tcpdump and using various
> ldapsearch options I noticed that if the client doesn't request starttls
> or connect on 636 is is possible to grab a users ldap record and the
> transmission is in clear text.

Yup...

> If I authenticate to the server using the -W option to ldapsearch the
> record is sent with the SSHA encrypted password.

No, -W has nothing to do with it.  ldaps:// or -Z(Z) does.
Packet-sniff "ldapwhoami -xh ldap://<server>/ -W" without -Z to see.

> I guess this behavior is expected since the server is listening on 389
> and it is up to the client to initialize the starttls session, but I was
> wondering if there was a way to force the server to only use starttls on
> 398 and not rely on the the client to set up starttls?

No, it's the client which takes the initiative to send Bind with an
unencrypted password as its first network packet, without a StartTLS
first.  The best you can do is to make the server complain in the
hope that the user will learn to Not Do That.  We use this:

    security  simple_bind=128 update_ssf=128
    localSSF  128

The first returns the error "Confidentiality required" to Bind and
update requests with security strength < 128, the 2nd raises the
security strength which slapd considers ldapi:// to have, so we
don't receive that error when updating the database over ldapi://.

(I don't know what would be good values nowadays, the rationale
of these numbers are lost in the mist of time.  The default for
localSSF is 71, so maybe that's fine for security too.)

> One option
> would be to only have the server start on 636 and not have it listen on
> 389, but we would like to keep the same functionality if possible.  Am I
> missing something obvious? The only option that I see as a possiblity is
> the TLSVerifyClient { never | allow | try | demand } in slapd.conf. 
> But, it's unclear to me if this will provide the desired effect.

It won't.  That is about what happens when the client does use TLS, it
doesn't affect what happens when it doesn't.

-- 
Hallvard