I'm trying to avoid mistakes and configure a server and/or client to force the use of start tls. So, if someone binds to the server and accidentally forgets to configure start_tls on the client, the connection is rejected.
The problem is that the rejection happens too late: the client password was already sent to the server in clear test.
So far I have tested using acls (ssf=56) and the global "security" setting with ssf, simple_bind and transport. In all cases, the unencrypted access is rejected, but too late: the password was sent.
I guess what I need is a setting in /etc/openldap/ldap.conf similar to the sasl minssf property, but for non-sasl binds. Is there such a thing? Something that would behave as if -ZZ was always added to the openldap command-line tools.
Andreas Hasenack writes:
I'm trying to avoid mistakes and configure a server and/or client to force the use of start tls. So, if someone binds to the server and accidentally forgets to configure start_tls on the client, the connection is rejected.
The problem is that the rejection happens too late: the client password was already sent to the server in clear test.
If you want to ensure it on the server side, all you can do is not listen for ldap:// connections since they start out unencrypted. ldap:// connections have no initial protocol exchange which the server can reject. Instead listen to ldaps://, "LDAP over SSL (aka TLS)".
I guess what I need is a setting in /etc/openldap/ldap.conf similar to the sasl minssf property, but for non-sasl binds. Is there such a thing? Something that would behave as if -ZZ was always added to the openldap command-line tools.
Yes.
URI ldaps://fully.qualified.server-hostname/ TLS_CACERT <file with the CA-certificate which signed the server cert> TLS_REQCERT demand
On Wed, Jul 04, 2007 at 05:53:24PM +0200, Hallvard B Furuseth wrote:
The problem is that the rejection happens too late: the client password was already sent to the server in clear test.
If you want to ensure it on the server side, all you can do is not listen for ldap:// connections since they start out unencrypted. ldap:// connections have no initial protocol exchange which the server can reject. Instead listen to ldaps://, "LDAP over SSL (aka TLS)".
I guess what I need is a setting in /etc/openldap/ldap.conf similar to the sasl minssf property, but for non-sasl binds. Is there such a thing? Something that would behave as if -ZZ was always added to the openldap command-line tools.
Yes.
URI ldaps://fully.qualified.server-hostname/ TLS_CACERT <file with the CA-certificate which signed the server cert> TLS_REQCERT demand
The only problem is that I really want start_tls, and not ldaps (which is deprecated, right?).
Andreas Hasenack writes:
URI ldaps://fully.qualified.server-hostname/ TLS_CACERT <file with the CA-certificate which signed the server cert> TLS_REQCERT demand
The only problem is that I really want start_tls, and not ldaps (which is deprecated, right?).
Don't know. It's nonstandard, anyway. But I doubt it'll go away anytime soon. I can't find an ldap.conf statement to match '-ZZ' either.
Note that if you do use 'URI ldaps://' in ldap.conf, you'll still be able to use ldap:// on the command line if your server listens to it after all. But that's all I can think of.
On Wed, 4 Jul 2007, Andreas Hasenack wrote: ...
The only problem is that I really want start_tls, and not ldaps (which is deprecated, right?).
Can't be done. The problem is that LDAP does not mandate that clients perform any sort of capability negotiation before performing a bind. Ergo, there's no way to say "unprotected binds are not accepted" and expect clients to obey it. As Hallvard said, "ldap:// connections have no initial protocol exchange which the server can reject". If you trace an LDAP connection, you'll see that the bind is the very first application data, so there's no way for the server to see whether the client is sending a permissible request until it's too late.
Philip Guenther
On Wednesday 04 July 2007 15:52:45 Philip Guenther wrote:
On Wed, 4 Jul 2007, Andreas Hasenack wrote: ...
The only problem is that I really want start_tls, and not ldaps (which is deprecated, right?).
Can't be done. The problem is that LDAP does not mandate that clients
I realized by now it can't be done at the protocol level. But it could be done by the client library. Not as a "mandatory" option, but an initial default. That would be sufficient for me.
Andreas Hasenack writes:
I realized by now it can't be done at the protocol level. But it could be done by the client library. Not as a "mandatory" option, but an initial default. That would be sufficient for me.
Yes, a "TLS on/off" ldap.conf option. We'd also need an anti-"-Z" command line option too to turn it off. Also it would be useful if the -Z (and "TLS on") options were ignored when using 'ldaps:' URLs.
On Thu, 5 Jul 2007, Hallvard B Furuseth wrote:
Andreas Hasenack writes:
I realized by now it can't be done at the protocol level. But it could be done by the client library. Not as a "mandatory" option, but an initial default. That would be sufficient for me.
Yes, a "TLS on/off" ldap.conf option. We'd also need an anti-"-Z" command line option too to turn it off. Also it would be useful if the -Z (and "TLS on") options were ignored when using 'ldaps:' URLs.
It should probably be ignored for ldapi: URLs too. The only reason to use TLS with ldapi: is if you want to use SASL EXTERNAL with a client certificate instead of the ldapi transport credentials, which is a pretty small corner case.
Hmm, maybe it should be stated in term of a required Security Strength Factor, like the server does. Then the TLS requirement could be automatically bypassed when using ldapi or authenticating with GSSAPI. The ldaps case might even work automatically that way too.
Philip Guenther
Hallvard B Furuseth wrote:
Andreas Hasenack writes:
I realized by now it can't be done at the protocol level. But it could be done by the client library. Not as a "mandatory" option, but an initial default. That would be sufficient for me.
Yes, a "TLS on/off" ldap.conf option. We'd also need an anti-"-Z" command line option too to turn it off. Also it would be useful if the -Z (and "TLS on") options were ignored when using 'ldaps:' URLs.
Indeed, that's what the TLS keyword was for in ldap.conf, with its try / demand / hard options, but it was never fully implemented. And then it was removed...
On Wednesday, 4 July 2007, Andreas Hasenack wrote:
On Wed, Jul 04, 2007 at 05:53:24PM +0200, Hallvard B Furuseth wrote:
The problem is that the rejection happens too late: the client password was already sent to the server in clear test.
If you want to ensure it on the server side, all you can do is not listen for ldap:// connections since they start out unencrypted. ldap:// connections have no initial protocol exchange which the server can reject. Instead listen to ldaps://, "LDAP over SSL (aka TLS)".
I guess what I need is a setting in /etc/openldap/ldap.conf similar to the sasl minssf property, but for non-sasl binds. Is there such a thing? Something that would behave as if -ZZ was always added to the openldap command-line tools.
Yes.
URI ldaps://fully.qualified.server-hostname/ TLS_CACERT <file with the CA-certificate which signed the server cert> TLS_REQCERT demand
The only problem is that I really want start_tls, and not ldaps (which is deprecated, right?).
IMHO, a non-working solution (e.g. where encryption can't be forced from the client side) cannot be the only alternative for a feature supposedly deprecated (ldaps, where it is possible).
At a minimum, there should be some way to force start_tls for OpenLDAP client utilities before claiming a feature is deprecated.
(Yes, this has been irritating me for a long time too ...).
Regards, Buchan
On Jul 5, 2007, at 10:39 AM, Buchan Milne wrote:
IMHO, a non-working solution (e.g. where encryption can't be forced from the client side) cannot be the only alternative for a feature supposedly deprecated (ldaps, where it is possible).
It's not intended that there be a way to force use of ldaps:// or Start TLS. ldap.conf(5) provides defaults, not as a policy statement mechanism. The defaults are intended only to be used when the user has not specified what she wants to do. For instance, the URI is only used if the user doesn't specify a -H (or -h) option.
If the user cannot override the default, it's not a default! Some settings were added that the user cannot override. These should be considered flawed.
As I'm sure I've noted many times before, if I had to do it over again, there would be no ldap.conf(5). The library should be dealing with program defaults. The program should be. The library should expect the program to provide all the parameters the library needs to operate well. But I digress...
At a minimum, there should be some way to force start_tls for OpenLDAP client utilities before claiming a feature is deprecated.
(Yes, this has been irritating me for a long time too ...).
Regards, Buchan
On Thu, Jul 05, 2007 at 11:13:23AM -0700, Kurt Zeilenga wrote:
As I'm sure I've noted many times before, if I had to do it over again, there would be no ldap.conf(5). The library should be dealing with program defaults. The program should be. The library should expect the program to provide all the parameters the library needs to operate well. But I digress...
While this works, it's also very convenient to have the library configuration file to specify certain parameters and behaviour.
openldap-software@openldap.org
-
Andreas Hasenack -
Buchan Milne -
Hallvard B Furuseth -
Howard Chu -
Kurt Zeilenga -
Philip Guenther