[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldapi without TLS and ldap with TLS?


Thank you for your feedback Philip. Comments inline.

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. So I thought I give that app access via a socket and secure the rest with TLS + olcTLSVerifyClient: demand. If there is a better way to solve this then I am all ears.
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 :-) 

[snip]


Until you describe *why* you're doing something, you can't know whether
you're actually acheiving it.


See problem description above.


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. 


olcSecurity: tls=256  <---


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 :-) 


My guess, not knowing your actual _purpose_, would be you want to require
a minssf of some 256, and give local (ldapi://) connetions that same SSF.
Hopefully my intentions are clear from what I described above: TLS (256) with client cert auth on anything but ldapi so I can give the locally running app access to the LDAP server via a socket. 


Of course, that doesn't stop a client from connecting and sending a BIND
request in cleartext.  It won't succeed, but it'll still go out in
cleartext.
That's clear. Access to the box is only possible via a VPN and there's no pubic access to the LDAP server. 

Regards,
Patrick