apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: svn commit: r124824 - /apr/apr-util/trunk/ldap/apr_ldap_option.c
Date Tue, 11 Jan 2005 18:08:51 GMT
Brad Nicholes wrote:

>   As the code stands now with only the Novell SDK always calling
> ldapssl_init(), is this a problem?

It is - suddenly you need to use APR differently if you are using 
Novell, as opposed to when you are using all the other toolkits which is 
what we're trying to avoid.

If you are forced to set the SSL mode to none|ssl|tls inside the
apr_ldap_init() step, you effectively prevent all non Novell platforms
from being able to set client certs on a connection (affecting
specifically OpenLDAP and Netscape/Mozilla, possibly Microsoft). Client 
cert settings must be defined after ldap_init() and before enabling 
either SSL or TLS on the connection.

According to the Novell docs, ldapssl_init() is equivalent to
ldap_init() followed by ldap_install_routines(), which was why I chose
that approach. The comment about ldap_install_routines() following
ldap_init() directly was vague in the docs: It said "success could not
be guaranteed", but it didn't clarify whether it meant
"ldap_install_routines() would fail neatly with an error message" or
"the library will crash". I am being optimistic and assuming "the 
library would fail neatly".

I suspect the warning is about trying to do ldap_init(), followed by
ldap_bind(), followed by ldap_install_routines() (which will fail, as
the connection is now finalised at the ldap_bind() step).

> One thing that bothered me while I was testing this.  Even if the
> start_tls fails, authentication still succeeds and content is returned. 
> Since we are assuming forced TLS, authentication should fail if the TLS
> connection fails.  It probably shouldn't be allowed to fall back to
> unsecure.

This is the app's problem though - if starttls fails it will return an
error, and it's normal on error to give up, which is the expected
behaviour. If the app chooses to ignore the error and go on with the
insecure connection, then it was the app's choice - it may have wanted
to do so. I think it should be pretty clearly documented that this is 
the case though.


View raw message