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

Re: ldapi without TLS and ldap with TLS?

Hi Philip,

Thank you for your elaborate feedback. Comments inline.

On 02/19/2013 03:42 AM, Philip Guenther wrote:
[snip]

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


Yes.

[snip]

   "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.
Yes. Client certificate authentication is used everywhere where possible (for things like corporate web access, email, VPN). 


(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.)
Thankfully the security overlords who came up with this one are also the ones who have to generate and manage the certs :-) 

[snip]


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 did not try to use ldapi with this setup. I used ldap on 127.0.0.1. Sorry if that was not clear. 

[snip]


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!
Agreed. The authentication via uid/gid is a nice one I did not know was possible. Will look into that. 


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
Your example had me stumped. Upon reading the olcLocalSSF section again I realized I made a mistake. Although it says "Specifies the Security Strength Factor (SSF) to be *given* local LDAP sessions" my mind munched it into "Specifies the Security Strength Factor (SSF) to *require* for local LDAP sessions". Obviously setting it to 0 did not help... Staring at the screen too long I guess. So thanks for making me read the man page again :-) 


But I haven't tested it.


Works like a charm.

[snip]


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


Duly noted.
Thank you very much for all your help and enlightening comments. Much appreciated. 

Regards,
Patrick