httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Auth LDAP ssl/tls differences
Date Thu, 06 Jan 2005 21:52:57 GMT
At 03:18 PM 1/6/2005, Graham Leggett wrote:
>Brad Nicholes wrote:
>
>>   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?
>
>Apparently ldap:// + STARTTLS is a standard, and ldaps:// is not a standard (although
it's universally supported). The end result of both methods is the same - a secure connection.

Yes.

>I personally feel more comfortable having LDAP on an SSL port only, then I know there
is no way my server can be accessed accidently without encryption in place. But others want
to use STARTTLS, and if it's technically possible, I see no reason to stop them.

Remember MANY httpd admins don't have any say-so about the backend
ldap servers that are administered by centralized IT departments.
And I agree, if the client/library doesn't support SSL, and the
user configures to AuthLDAPClientTLS on (or however we configure)
then we need to make certain apr_ldap enforces that desire, and
fails with intelligent feedback if it can't be supported.

The reason ldap: + STARTTLS is 'supported' is that there is a
general desire on the part of the wider RFC community to use
TLS upgrade in lieu of allocating explicit secondary SSL ports
for every protocol.

>>Something to think about - what about ldap connection caching?  Are the
>>ldap://+start_tls connections cached separately from ldap://  and
>>ldaps:// connections?
>
>No - there is just one cache of connections. SSL/TLS is negotiated when the connection
is first established, and remains that way until the connection is closed. Whether the initial
negotiation was SSL or STARTTLS makes no difference, once util_ldap has said STARTTLS it doesn't
stop TLS again until the connection is disposed of.
>
>This doesn't mean that APR-util doesn't support the concept of starting and stopping tls,
it only means that util_ldap doesn't choose to use this option.

And I suspect it would be overkill to support it.

Bill




Mime
View raw message