[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-technical
Subject:    Re: ldapi without TLS and ldap with TLS?
From:       Patrick Lists <openldap-list () puzzled ! xs4all ! nl>
Date:       2013-02-19 13:42:51
Message-ID: 5123815B.8030408 () puzzled ! xs4all ! nl
[Download RAW message or body]


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



[prev in list] [next in list] [prev in thread] [next in thread]