Re: ldapi without TLS and ldap with TLS?

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

On Mon, 18 Feb 2013, Patrick Lists wrote:
> On 02/18/2013 07:16 AM, Philip Guenther wrote:
> > On Mon, 18 Feb 2013, Patrick Lists wrote:
> > > I'm tying achieve the following with OpenLDAP RE24 from last week:
> > > 
> > > Connections on ldapi:/// are plain text and ldap connections require 
> > > TLS with client cert auth.
> > 
> > Perhaps it would be help if you started by answering, at least for 
> > yourself, what problem you're trying to solve.  For example, "prevent 
> > passwords from being sent on physical networks in the clear or under a 
> > symmetric cipher of fewer than 256bits"
> 
> The problem is that there is an application (running on the same box as 
> the LDAP server) which does not support client certificate 
> authentication yet it needs read-only access to the LDAP server.

That's the situation, but that's not a problem unless you have some sort 
of security requirement.  So, what's the security requirement?  I can 
imagine it being something like:

  "We need to protect corporate data in LDAP from being modified or even 
   accessed by untrusted resources.

The next question is then of course why do you want to require TLS 
w/client certs and not just "must bind with a password, with TLS to 
protect the passwords", which is much more common?  The answer might be 
something like:

  "Because some of the applications cannot be configured to bind 
   non-anonymously but they all (except for that one) _can_ be configured 
   to always use StartTLS and provide a client certificate, we want to 
   require that all ldap:// connections use the StartTLS operation with a 
   client cert before performing any LDAP operations that access or modify
   data.

(That's a complete guess and probably not your real reason.  Client certs 
are just another form of secret which are, IMO, a bigger pain to generate 
and manage.)



> I tried to figure out how to allow the app and clients access to 
> localhost without TLS and the rest with TLS + client cert auth using 
> what seems the only example in existence:
> 
> # first, make sure TLS or localhost
> access to *
> 	by tls_ssf=1 none break
> 	by peername.ip="127.0.0.1" none break
> 	by * none
>
> # "real" ACL(s) go here
> 
> But that did not work and the why this should work (assuming the example 
> is correct) eludes me, with the guide and man pages being of little help 
> as I'm no software developer nor do I have Einstein's brainpower :-)

Well, for starters, the peername.ip="127.0.0.1" clause does *NOT* match 
ldapi:// connections.  It matches ldap://127.0.0.1/ and ldaps://127.0.0.1/ 
connections.


> > > I thought I could do that with:
> > ...
> > > olcLocalSSF: 0  <---
> > 
> > So, you've told slapd that ldapi:// connections are to be treated as
> > completely insecure, like ldap:// conections without TLS.  That doesn't
> > seem to match your intention.
> 
> It does. Insecure socket access for the app which does not support 
> client cert auth and TLS+client cert auth for access via ldap/ldaps.

In what way is an ldapi:// connection insecure?  It's a UNIX domain socket 
for which the data never goes over a physical net and that therefore 
cannot be snooped.  That's *MORE* secure than a TCP connection secured 
with TLS!  You can even authenticate it via the uid and gid of the process 
that opened the connection!


Anyway, if you want to permit only

a) read-only ldapi:// connections and

b) ldap:// connections using TLS w/client certs

then *I think* you can do that with three options in the config:

# require clients that clients that do TLS provide a client cert
olcTLSVerifyClient: demand
# treat ldapi:// connections as at least as secure as a 256bit cipher
olcLocalSSF: 256
# require connections to be at least as secure as a 256bit cipher to do 
# anything at all (the "ssf=256") clause, and specifically require that
# they be using TLS (and not just ldapi) with 256bit cipher to do updates
olcSecurity: ssf=256 update_tls=256


But I haven't tested it.


> > To quote slapd-config(5):
> >         olcSecurity: <factors>
> >                Specify a set of security strength factors (separated by
> > white
> >                space) to require (see olcSaslSecprops's minssf option for a
> >                description of security strength factors).  The directive may
> > be
> >                specified globally and/or per-database.
> > ...
> >                tls=<n> specifies the TLS security strength factor.
> > 
> > So, this tells slapd to require *ALL* connections, regardless of how they
> > connect, to use SSL/TLS with an SSF of at least 256.  That clearly doesn't
> > match your intention.
> 
> Thank you for that explanation. It would have been nice if that section
> mentioned that it applies to *all* connections with no exceptions and no
> matter what else I might have configured. At least I learned something :-)

Yes, an unconditional "require blah" should be taken to be unconditional.


Philip Guenther