..."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?
----- 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.
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.
Josh.Mullis@cox.com wrote:
..."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. Certificates are only for authentication, not encrypting the traffic. Usually only servers have certificates, so that clients can verify they are talking to the server they expected, and not being spoofed. Client certificates are very useful to allow the server to verify a client's identity, but there are obviously many other mechanisms for that as well.
----- Original Message ----- From: Emmanuel Dreyfusmanu@netbsd.org To: Mullis, Josh (CCI-Atlanta); openldap-software@openldap.orgopenldap-software@openldap.org Sent: Sun Aug 23 02:59:05 2009 Subject: Re: tlsverifyclient security implications
Josh Mullisjosh.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.
Howard Chu wrote:
Josh.Mullis@cox.com wrote:
..."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. Certificates are only for authentication, not encrypting the traffic.
Howard, I'm sure that you already know this but let's be more precise with the wording to avoid confusing people:
Strictly speaking the *client cert* is only for authentication of the client. The public key in the server cert is also used for the secure key exchange for the symmetric cipher used and thus is indirectly used for encrypting the traffic (besides authenticating the server).
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Josh.Mullis@cox.com wrote:
..."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. Certificates are only for authentication, not encrypting the traffic.
Howard, I'm sure that you already know this but let's be more precise with the wording to avoid confusing people:
Strictly speaking the *client cert* is only for authentication of the client. The public key in the server cert is also used for the secure key exchange for the symmetric cipher used and thus is indirectly used for encrypting the traffic (besides authenticating the server).
But certificates are not a required element for encryption of a connection - after all, TLS also supports anonymous Diffie-Hellman key exchange.
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Josh.Mullis@cox.com wrote:
..."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. Certificates are only for authentication, not encrypting the traffic.
Howard, I'm sure that you already know this but let's be more precise with the wording to avoid confusing people:
Strictly speaking the *client cert* is only for authentication of the client. The public key in the server cert is also used for the secure key exchange for the symmetric cipher used and thus is indirectly used for encrypting the traffic (besides authenticating the server).
But certificates are not a required element for encryption of a connection - after all, TLS also supports anonymous Diffie-Hellman key exchange.
In theory, yes. But personally I don't know any real-world TLS deployment with anonymous Diffie-Hellman key exchange. I don't even know deployments with DSA-based certs.
Ciao, Michael.
Howard Chu hyc@symas.com wrote:
But certificates are not a required element for encryption of a connection - after all, TLS also supports anonymous Diffie-Hellman key exchange.
Sure, but encryption without authentication makes little sense, as you don't know who you are securely speaking to: you can get an encrypted link to a man in the middle.
Thank you all for your responses. You guys are awesome!
This is what I've been worried about with the encryption. I wanted to make sure the encryption was "secure", so to speak.
-Josh
On Mon, 2009-08-24 at 08:30 -0400, Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
But certificates are not a required element for encryption of a connection - after all, TLS also supports anonymous Diffie-Hellman key exchange.
Sure, but encryption without authentication makes little sense, as you don't know who you are securely speaking to: you can get an encrypted link to a man in the middle.
On Mon, 24 Aug 2009, Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
But certificates are not a required element for encryption of a connection - after all, TLS also supports anonymous Diffie-Hellman key exchange.
Sure, but encryption without authentication makes little sense, as you don't know who you are securely speaking to: you can get an encrypted link to a man in the middle.
Heh, I have this vision of libldap changing the default cipher suite based on the TLS_VERIFY setting, such that any setting that doesn't do complete validation of certs would have the library prefer to use an anonymous cipher suite instead.
"You're not actually protecting yourself against MitM attacks, so we're enabling the lower-latency anonymous suites."
(...at least my memory is that the ADH handshake is cheaper than the RSA handshake...)
Philip Guenther
openldap-software@openldap.org
-
Eric MSP Veith -
Howard Chu -
Josh Mullis -
Josh.Mullis＠cox.com
-
manu＠netbsd.org -
Michael Ströder -
Philip Guenther