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
