Hi,
I'm trying to get slapd to reject non-encrypted connections, but nowhere can I find how you configure it to *only* accept TLS traffic. I just confirmed that our server accepts unencrypted traffic (with ldapsearch and tcpdump). Normally, I would just close the non-SSL port with IP tables, but using the SSL port is deprecated, apparently, so I don't have that option.
So, with the cn=config SSL configuration commands, like this:
dn: cn=config changetype:modify replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/bla.key - replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/bla.crt - replace: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/ca.pem
Is there a param for forcing TLS? I tried:
dn: cn=config changetype: modify replace: olcTLSCipherSuite olcTLSCipherSuite: TLSv1+RSA:!NULL
but it doesn't work; the server doesn't start. Debug output:
TLS: could not set cipher list TLSv1+RSA:!NULL. main: TLS init def ctx failed: -1 slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy.
Nor does "olcTLSCipherSuite: HIGH" work.
I looked in the openldap source code, but even there, I can't find how to do it.
Slapd: 2.4.21-0ubuntu5.7 Ubuntu: Ubuntu 10.04.4 LTS
Thanks,
Wiebe Cazemier
On Dec 21, 2012, at 10:00 AM, Wiebe Cazemier wiebe@halfgaar.net wrote:
Hi,
I'm trying to get slapd to reject non-encrypted connections, but nowhere can I find how you configure it to *only* accept TLS traffic. I just confirmed that our server accepts unencrypted traffic (with ldapsearch and tcpdump). Normally, I would just close the non-SSL port with IP tables, but using the SSL port is deprecated, apparently, so I don't have that option.
So, with the cn=config SSL configuration commands, like this:
dn: cn=config changetype:modify replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/bla.key
replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/bla.crt
replace: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/ca.pem
Is there a param for forcing TLS? I tried:
dn: cn=config changetype: modify replace: olcTLSCipherSuite olcTLSCipherSuite: TLSv1+RSA:!NULL
but it doesn't work; the server doesn't start. Debug output:
TLS: could not set cipher list TLSv1+RSA:!NULL. main: TLS init def ctx failed: -1 slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy.
Nor does "olcTLSCipherSuite: HIGH" work.
I looked in the openldap source code, but even there, I can't find how to do it.
Slapd: 2.4.21-0ubuntu5.7 Ubuntu: Ubuntu 10.04.4 LTS
I added an olcSecurity attribute to the database directives for the parts of the server's DIT where I wish to require TLS. To start with I set the value "tls=1".
See also:
http://itsecureadmin.com/tag/openldap/
----- Original Message -----
From: "Chuck Lever" chuck.lever@oracle.com To: "Wiebe Cazemier" wiebe@halfgaar.net Cc: openldap-technical@openldap.org Sent: Friday, 21 December, 2012 4:39:21 PM Subject: Re: Forcing TLS encryption
...
I added an olcSecurity attribute to the database directives for the parts of the server's DIT where I wish to require TLS. To start with I set the value "tls=1".
See also:
http://itsecureadmin.com/tag/openldap/
-- Chuck Lever chuck[dot]lever[at]oracle[dot]com
I got it to work (connection won't be allowed without TLS), but I can still capture the password with tcpdump. To elaborate:
I successfully set tls=1 with:
dn: cn=config changetype: modify add: olcSecurity olcSecurity: tls=1
When I do an ldapsearch now, it says TLS is required:
$ ldapsearch ldapsearch -Hldap://myhost:389 -D"uid=user,ou=people,dc=domain,dc=com" -W Enter LDAP Password: ldap_bind: Confidentiality required (13) additional info: TLS confidentiality required
However, when I capture the traffic with tcpdump, I can still see the password being sent. With FTP require TLS, the server rejects the connection after the login command, so you don't get the chance to send your password. Is there a way to do that here too?
Am Mon, 24 Dec 2012 10:14:39 +0100 (CET) schrieb Wiebe Cazemier wiebe@halfgaar.net:
----- Original Message -----
From: "Chuck Lever" chuck.lever@oracle.com To: "Wiebe Cazemier" wiebe@halfgaar.net Cc: openldap-technical@openldap.org Sent: Friday, 21 December, 2012 4:39:21 PM Subject: Re: Forcing TLS encryption
...
I added an olcSecurity attribute to the database directives for the parts of the server's DIT where I wish to require TLS. To start with I set the value "tls=1".
See also:
http://itsecureadmin.com/tag/openldap/
-- Chuck Lever chuck[dot]lever[at]oracle[dot]com
I got it to work (connection won't be allowed without TLS), but I can still capture the password with tcpdump. To elaborate:
I successfully set tls=1 with:
dn: cn=config changetype: modify add: olcSecurity olcSecurity: tls=1
When I do an ldapsearch now, it says TLS is required:
$ ldapsearch ldapsearch -Hldap://myhost:389 -D"uid=user,ou=people,dc=domain,dc=com" -W Enter LDAP Password: ldap_bind: Confidentiality required (13) additional info: TLS confidentiality required
In order to initiate Transport Layer Security you have to call the extended operation ldapSTARTTLS.
-Dieter
----- Original Message -----
From: "Dieter Klünter" dieter@dkluenter.de To: openldap-technical@openldap.org Sent: Thursday, 27 December, 2012 3:53:21 PM Subject: Re: Forcing TLS encryption
Am Mon, 24 Dec 2012 10:14:39 +0100 (CET) schrieb Wiebe Cazemier wiebe@halfgaar.net:
In order to initiate Transport Layer Security you have to call the extended operation ldapSTARTTLS.
-Dieter
-- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E
I understand that, but this way, even when you're forcing TLS, users can still expose their passwords if their computers are mal-configured. SMTP, IMAP, FTP, etc don't allow this, because they reject the connection if LOGINNAME is given before STARTTLS.
It's kind of a security issue. Is it because in LDAP, username and password are given as one command, and the server doesn't have the chance to abort at that point? If so, then I guess it's unavoidable.
Am Fri, 28 Dec 2012 09:14:51 +0100 (CET) schrieb Wiebe Cazemier wiebe@halfgaar.net:
----- Original Message -----
From: "Dieter Klünter" dieter@dkluenter.de To: openldap-technical@openldap.org Sent: Thursday, 27 December, 2012 3:53:21 PM Subject: Re: Forcing TLS encryption
Am Mon, 24 Dec 2012 10:14:39 +0100 (CET) schrieb Wiebe Cazemier wiebe@halfgaar.net:
In order to initiate Transport Layer Security you have to call the extended operation ldapSTARTTLS.
-Dieter
-- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E
I understand that, but this way, even when you're forcing TLS, users can still expose their passwords if their computers are mal-configured. SMTP, IMAP, FTP, etc don't allow this, because they reject the connection if LOGINNAME is given before STARTTLS.
No. RFC 4513 clearly states:
... however, where a client intends to perform both a Bind operation and a StartTLS operation, it SHOULD first perform the StartTLS operation so that the Bind request and response messages are protected by the data security services established by the StartTLS operation. [...]
-Dieter
On Fri, 28 Dec 2012, Wiebe Cazemier wrote:
I understand that, but this way, even when you're forcing TLS, users can still expose their passwords if their computers are mal-configured. SMTP, IMAP, FTP, etc don't allow this, because they reject the connection if LOGINNAME is given before STARTTLS.
That is not true of SMTP's AUTH PLAIN, IMAP's AUTHENTICATE PLAIN, or IMAP's LOGIN. The PLAIN SASL mechanism and IMAP's LOGIN command both send the username and password without waiting for a response from the server**.
It's kind of a security issue. Is it because in LDAP, username and password are given as one command, and the server doesn't have the chance to abort at that point? If so, then I guess it's unavoidable.
Correct.
Philip Guenther
** Well, to be completely accurate, IMAP AUTHENTICATE requires a server response if the server doesn't support the SASL-IR capability
----- Original Message -----
From: "Philip Guenther" guenther+ldaptech@sendmail.com To: "Wiebe Cazemier" wiebe@halfgaar.net Cc: "Dieter Klünter" dieter@dkluenter.de, openldap-technical@openldap.org Sent: Friday, 28 December, 2012 9:36:50 PM Subject: Re: Forcing TLS encryption
On Fri, 28 Dec 2012, Wiebe Cazemier wrote:
I understand that, but this way, even when you're forcing TLS, users can still expose their passwords if their computers are mal-configured. SMTP, IMAP, FTP, etc don't allow this, because they reject the connection if LOGINNAME is given before STARTTLS.
That is not true of SMTP's AUTH PLAIN, IMAP's AUTHENTICATE PLAIN, or IMAP's LOGIN. The PLAIN SASL mechanism and IMAP's LOGIN command both send the username and password without waiting for a response from the server**.
It's kind of a security issue. Is it because in LDAP, username and password are given as one command, and the server doesn't have the chance to abort at that point? If so, then I guess it's unavoidable.
Correct.
Philip Guenther
** Well, to be completely accurate, IMAP AUTHENTICATE requires a server response if the server doesn't support the SASL-IR capability
Then why is the LDAPS port deprecated? If the connection is SSL from the start, you don't have this issue.
On Dec 28, 2012, at 12:56 PM, Wiebe Cazemier wiebe@halfgaar.net wrote:
----- Original Message -----
From: "Philip Guenther" guenther+ldaptech@sendmail.com To: "Wiebe Cazemier" wiebe@halfgaar.net Cc: "Dieter Klünter" dieter@dkluenter.de, openldap-technical@openldap.org Sent: Friday, 28 December, 2012 9:36:50 PM Subject: Re: Forcing TLS encryption
On Fri, 28 Dec 2012, Wiebe Cazemier wrote:
I understand that, but this way, even when you're forcing TLS, users can still expose their passwords if their computers are mal-configured. SMTP, IMAP, FTP, etc don't allow this, because they reject the connection if LOGINNAME is given before STARTTLS.
That is not true of SMTP's AUTH PLAIN, IMAP's AUTHENTICATE PLAIN, or IMAP's LOGIN. The PLAIN SASL mechanism and IMAP's LOGIN command both send the username and password without waiting for a response from the server**.
It's kind of a security issue. Is it because in LDAP, username and password are given as one command, and the server doesn't have the chance to abort at that point? If so, then I guess it's unavoidable.
Correct.
Philip Guenther
** Well, to be completely accurate, IMAP AUTHENTICATE requires a server response if the server doesn't support the SASL-IR capability
Then why is the LDAPS port deprecated? If the connection is SSL from the start, you don't have this issue.
You still have the issue that the client might be configured for ldap://host:636 and Simple Bind or SASL PLAIN (generally by user mis-configuration).
In short, nothing in the server can prevent a poorly coded or poorly configured client from disclosing a user password in appropriately.
ldaps:// was never standardized and hence deprecated. There were many reasons why the IETF choose not to standardize ldaps://, one being interoperability issues between pre-existing implementations... another being that it viewed as not needed.
-- Kurt
openldap-technical@openldap.org
-
Chuck Lever -
Dieter Klünter -
Kurt Zeilenga -
Philip Guenther -
Wiebe Cazemier