Re: svn commit: r124824 - /apr/apr-util/trunk/ldap/apr_ldap_option.c

[Brad Nicholes <BN...@novell.com>]

   So you will need to clarify one thing for me and we will probably
have to both do a little more testing.  The Novell docs state that
ldapssl_init(,,0) is the same as ldap_init().  The only difference is
that the potential connection has been prepared to become an SSL/TLS
connection if desired.  Where an ldapssl_init(,,1) forces the connection
to be SSL.  Is this true for other SDKs.  If so, then there shouldn't be
a problem calling ldapssl_init(,,0), adding the client certificate and
then telling it to become and SSL/TLS connection, correct?  

   The problem that I have found on the Novell SDK is that if I call
ldap_init() rather than ldapssl_init(,,0), the connection is forced to
be unsecure.  In other words, ldapssl_start_tls() fails for that
connection.  If I call ldap_init() followed by
ldapssl_install_routines() then the connection is forced to be secure
and ldap_start_tls() also fails.  The only way to establish a TLS
connection is by calling ldapssl_init(,,0) followed by
ldapssl_start_tls() which means without the #ifdef in the code as it
stands, the Novell SDK can't do start_tls.  But this should have no
effect on the way other SDKs work.  I haven't done any testing with
mutual authentication, so I don't know what the gotchas are there yet. 
But for the Novell SDK, I should be able to call ldapssl_init(,,0), set
the client certificate and then call ldapssl_start_tls().  I should also
be able to call ldapssl_init(,,1) and just make sure that I set the
client certificate before calling ldap_bind().  The docs also state that
there is no communication or connection established until the
ldap_bind() happens.  Which should mean that as long as all the
certificates are in place before the ldap_bind() call, things should be
good.

Brad

>>> Graham Leggett <mi...@sharp.fm> Tuesday, January 11, 2005
11:08:51 AM >>>
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.

Regards,
Graham
--