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