Regarding LDAP, Apache is a client which must adhere to how
the LDAP server is configured, be that a secure port (ldaps://)
or via an unsecure connection (ldap://) that can be upgraded with
a StartTLS. It appears, from the OpenLdap perspective, that
use of ldaps:// is depricated in favor of StartTLS over ldap://.
See the following links on OpenLdap website:
http://www.openldap.org/faq/index.cgi?_highlightWords=ldaps&file=605
http://www.openldap.org/lists/openldap-software/200201/msg00042.html
http://www.openldap.org/lists/openldap-software/200206/msg00387.html
HTH,
-tony
-----Original Message-----
From: Brad Nicholes [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 06, 2005 8:13 AM
To: [email protected]; [EMAIL PROTECTED]
Subject: Re: Auth LDAP ssl/tls differences
I guess I am still a little unclear on what the advantage is to using
ldap:// + start_tls vs. ldaps://. The end result is the same except
that you have a secure connection to the LDAP server on 389 rather than
636. Is that the only reason? Administrators don't want to open a
dedicated SSL port to their LDAP server? I thought that the advantage
of start_tls was to be able to initiate an unsecure long-lived
connection and then when required, converting it to a secure connection
for a period time and then possible back to unsecure again. In other
words, the ability to bounce back and forward from an unsecure
connection to a secure connection.
Since the ldap communication between the httpd server and the ldap
server is "basically" a single authorization request and response, there
is no point in which an initial unsecure connection can be converted to
a secure connection except when the connection is established initially.
The connection is either entirely secure or not. As far as util_ldap
is concerned, it seems like just another way of doing the same thing.
If you want a secure connection to the LDAP server, just use ldaps://.
Unless I am missing something, ldap:// + start_tls isn't really buying
you anything.
Something to think about - what about ldap connection caching? Are the
ldap://+start_tls connections cached separately from ldap:// and
ldaps:// connections? Or do they keep flip-flopping back and forth as
required by the http request? If they keep flip-flopping, it seems like
a lot of overhead just to get a secure connection. If they are cached
separately then we are just implementing another secure connection cache
when we already have one.
If I am completely missing the point, then please correct me.
Brad
>>> [EMAIL PROTECTED] Tuesday, January 04, 2005 12:40 PM >>>
It seems that our support for ssl/tls with mod_ldap is considerably
confusing and frustrating for users. The recent interest in fixing
support for the Solaris/Netscape/Mozilla library reminded me of the fact
that we need to finish thinking this through.
Fast summary for those less familiar; there are two SSL schemas for LDAP
communications.
. Solaris/Netscape/Mozilla support is based on explicit SSLv3
connection to the ldaps:// port, 636.
. OpenLDAP supports ldaps://, it also supports STARTTLS
protocol over port 389. STARTTLS should not be invoked by
the scheme ldaps:// (it's a semantic error - ldaps:// should
not refer to an upgraded SSL connection, and would imply
port 636 which is not correct for this protocol.)
The correct scheme/port for STARTTLS LDAP connections is ldap:// with
port 389 implicit. We need a mechanism to clarify to mod_ldap that TLS
security is desired.
Incident http://issues.apache.org/bugzilla/show_bug.cgi?id=31443
offers a solution which we should consider adopting. As I was asking
for some offline feedback - Graham mentioned that some implementations
use the URL to specify that STARTTLS is desired.
But without some references the proposal seems to be a better option -
we shouldn't be redefining the ldap:// URI space.
Does anyone have any references to specifying STARTTLS as part of the
URI to the ldap server? Any other comments on this patch before I
integrate into httpd-2.1?
Bill
