Re: proposal, library error codes for TLS failures

[Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>]

Jan VÄelÃk wrote:
> People from SSSD would like to have a better information when some
> TLS operation in OpenLDAP library fails, instead of a general
> LDAP_CONNECT_ERROR. I already mentioned it on this list some time 
> ago:
> http://www.openldap.org/lists/openldap-devel/201105/msg00011.html
>
> I can write a patch for this, but I would like to discuss it with you 
> before.
>
> I already tried something. I added LDAP_TLS_INITIALIZATION_ERROR
> (-19) and LDAP_TLS_NEGOTIATION_ERROR (-20) API error codes and
> slightly modified the TLS code in OpenLDAP to propagate the errors.
> These two new error codes are sufficient for SSSD.
>
> Currently I have covered only the code for Mozilla NSS backend and it
> still needs some tunings. I would like to know, if adding the error
> codes this way is acceptable. Should I proceed? Or should it be done 
> a
> different way?

This suggestion makes me itchy in so many ways.


About the -Z option (attempted TLS without verification):

If I understand your message of 2011 correctly:
   http://www.openldap.org/lists/openldap-devel/201105/msg00011.html
the client may decide to talk the straight LDAP protocol (without TLS)
to a server which expects TLS.  Clearly that's wrong - the client's
valid options at that point are to talk TLS, disconnect, or tear down
the TLS connection before talking plain LDAP.


However.  Do not use -Z.  Use -ZZ.  The single -Z option should be 
axed.
Also TLS_REQCERT needs a big red warning.

-Z is a request for a security hole.  Users should not be required to
know that.  There may be rare valid reasons to use -Z, but an option 
for
that should not be the most obvious way to request TLS.

When the client requests TLS, it normally wants to do something which
needs a trusted connection.  Like sending a password with Simple Bind.
If the client happily proceeds after TLS failure, it'll be sending that
password over an unencrypted connection.

The server is happy, it doesn't get a bad TLS connection, and maybe
it'll reject the unprotected Bind.  But that's too late.  The
unencrypted password has already been sent.  Similarly, turning off
TLS_REQCERT opens for connection hijacking/man-in-the-middle attacks.
(You get a perfectly good TLS connection to the attacker.)


About changing result codes, assuming you still want that:

I don't know TLS programming.  Can you get the info you want from
ldap_get_option LDAP_OPT_X_TLS_CTX or LDAP_OPT_X_TLS_SSL_CTX?  If not,
maybe libldap could save some extra TLS info for the client.


I'd like to see API error codes improved.  My favorite is to split
LDAP_SERVER_DOWN in at least "could not connect" and "connection lost".

However, we need to be reluctant to change the result code for a given
situation.  Changes can break existing code which cares for that
situation and handles the current result code.  Such changes belong in
the switch to OpenLDAP 2.5 or 3.0.

For 2.4 I suggest ldap_set_option(ld, LDAP_CODE_POLICY, 
&policy_version)
or something like that, to request different result codes.  Either 
that,
or in your case libldap could store the TLS state somewhere so some API
call could get at it.  Like LDAP_OPT_X_TLS* mentioned above.

The LDAP_CODE_POLICY approach needs a general brainstorm about result
codes, so we don't end up with too many different policies to support.
Just changing two code which one application needs doesn't sound good.
Then next time we add one more, then two more, each time adding a new
policy version -- and soon enough we have a dozen different policies
and an utter mess in libldap where it tries to keep track of them all.

Hallvard