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
Re: Auth LDAP ssl/tls differences
At 10:12 AM 1/6/2005, 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? SunOne Directory servers support only ldaps:// SSLv3. Most OpenLDAP servers are configured only STARTTLS ldap:// TLSv1. Pretty significant difference, and a reason to support both of the protocols with any client that is able. Bill
RE: Auth LDAP ssl/tls differences
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=ldapsfile=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: dev@httpd.apache.org; [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
Re: Auth LDAP ssl/tls differences
Bennett, Tony - CNF wrote: 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://. It seems it is possible for OpenLDAP to support both ldaps:// and ldap:// + STARTTLS, however this is done using ldap_set_option(): http://www.openldap.org/lists/openldap-software/200409/msg00617.html Both ldap:// + STARTTLS and ldaps:// are supported on both the Novell and OpenLDAP toolkits in APR-util v1.1 as of a few days ago. Microsoft SDK support should follow shortly. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Auth LDAP ssl/tls differences
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. 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. 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. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Auth LDAP ssl/tls differences
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
Re: Auth LDAP ssl/tls differences
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. Call me paranoid, but I completely agree. Especially since the primary purpose of auth_ldap is authentication, ie. userid's and passwords and constantly being passed on the wire. 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. So we should probably split start_tls out from apr_ldap_ssl_init() into it's own API. This way some other module or application built on top of apr-util will have the ability to start and stop TLS at will. Brad [EMAIL PROTECTED] Thursday, January 06, 2005 2:18 PM 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. 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. 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. Regards, Graham --
Re: Auth LDAP ssl/tls differences
At 05:19 PM 1/6/2005, Brad Nicholes wrote: 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. So we should probably split start_tls out from apr_ldap_ssl_init() into it's own API. This way some other module or application built on top of apr-util will have the ability to start and stop TLS at will. Can anyone provide an example of why this would be useful? Otherwise it makes sense just to have one API, and let the user choose the flavor based on their server config (https://, or AuthLDAPClientTLS on). Our job in apr-util is to make developers lives easier, not more complicated, for the typical situations. Bill
Re: Auth LDAP ssl/tls differences
Off the top of my head, performance. Maybe you really only need a secure connection during the bind but after that switching back to an unsecure connection would perform better. Maybe you want to hold a connection pool of LDAP connections that can be used to transfer sensitive information or clear information that is only determined at the time of the request. Maybe you want to allow for connections that start out as anonymous binds to access public information and then can be rebound using the user credentials over a secure connection. Who knows, but it seems like it would have the same type of application that TLS upgrade would have in mod_ssl. Brad [EMAIL PROTECTED] Thursday, January 06, 2005 4:44 PM At 05:19 PM 1/6/2005, Brad Nicholes wrote: 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. So we should probably split start_tls out from apr_ldap_ssl_init() into it's own API. This way some other module or application built on top of apr-util will have the ability to start and stop TLS at will. Can anyone provide an example of why this would be useful? Otherwise it makes sense just to have one API, and let the user choose the flavor based on their server config (https://, or AuthLDAPClientTLS on). Our job in apr-util is to make developers lives easier, not more complicated, for the typical situations. Bill
Re: Auth LDAP ssl/tls differences
William A. Rowe, Jr. said: 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. I have just taught's apr-utils' apr_ldap_init() function to handle STARTTLS in addition to SSL (or no encryption). apr_ldap_init() supports an integer secure, which presently takes the values 0 for no encryption, and 1 for SSL. This now also takes the values 2 for STARTTLS, 3 for STARTTLS allowed if the server requested it, and 4 for optionally try STARTTLS. (All of this comes from OpenLDAP symantics, which some googling seems to be the new standard method for replacing deprecated legacy functions like ldap_start_tls_s()). This way apr_ldap_init() is extended to support STARTTLS while maintaining backwards compatibility. The next task is to modify httpd's util_ldap so it knows about the above extended behaviour. Regards, Graham --
Auth LDAP ssl/tls differences
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
Re: Auth LDAP ssl/tls differences
On Jan 4, 2005, at 2:40 PM, William A. Rowe, Jr. wrote: 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? +1 for adding it in... Even better if it's made into a branch for development before folding back into HEAD (yeah svn!) but no matter what, let's fold it in an start cracking on it.
Re: Auth LDAP ssl/tls differences
William A. Rowe, Jr. said: 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. Doing some Googling, it seems that an out of url directive seems to be the way everyone else is handling it. Let me look at this patch - it will probably need some reworking to fit in with the binary compatibility requirements of APR, but I need an LDAP enabled release of APR in the next few days, so there is an urgency to finish this off :) Regards, Graham --
