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

Re: tlsverifyclient security implications



Am Sonntag, 23. August 2009 19:29:28 schrieb Josh.Mullis@cox.com:
> ..."If the client does not send a certificate, it can still connect."
> 
> 
> Does that mean that traffic is still encrypted if a certificate is not
>  used?

Yes, it does.

One would commonly expect because of the typical HTTPS behaviour that only 
the server has to authenticate itself, i.e. provide a valid, signed 
certificate. However, the server may also ask the client to authenticate 
itself with a valid certificate. In such cases, the administrator has set up 
a public key/certificate infrastructure. This is common e.g. with (Open-) 
VPN, where not password logins, but certificates are the recommended way of 
establishing a authenticated, authorized tunnel.

OpenLDAP behaves in a similar way, thus "tlsverifyclient allow" triggers the 
behaviour one knows from a typical HTTPS browser session.

		-- Eric

> 
> 
> 
> 
> ----- Original Message -----
> From: Emmanuel Dreyfus <manu@netbsd.org>
> To: Mullis, Josh (CCI-Atlanta); openldap-software@openldap.org
>  <openldap-software@openldap.org> Sent: Sun Aug 23 02:59:05 2009
> Subject: Re: tlsverifyclient security implications
> 
> Josh Mullis <josh.mullis@cox.com> wrote:
> > What are the security implications concerning the following setting in
> > slapd.conf:
> > tlsverifyclient allow
> 
> As far as I understand, if the client sends a certificate, then slapd
> can use it to map client to a LDAP DN, like this:
> authz-regexp    cn=foo uid=foo,dc=example,dc=net
> 
> If the client does not send a certificate, it can still connect.
> 

Attachment: signature.asc
Description: This is a digitally signed message part.