During TLS negotiation, if a timeout is set, ldap_int_tls_start sets the
socket to non-blocking and calls ldap_int_poll in a loop if
ldap_int_tls_connect does not succeed the first time it is called.
However, ldap_int_poll sets the socket back to blocking and we currently
do not set it back to non-blocking. This means that a subsequent call to
ldap_int_tls_connect may hang and the configured timeout will not be
enforced. To fix this, we now set the socket back to non-blocking after
ldap_int_poll is called.
The test for async in ldap_int_tls_start was inverted, we already
support calling ldap_int_tls_connect repeatedly. And so long as
LBER_SB_OPT_NEEDS_* are managed correctly, the application should be
able to do the right thing.
Might require a new result code rather than reporposing
LDAP_X_CONNECTING for this.
Add LDAP_OPT_X_SASL_CBINDING option to define the binding type to use,
defaults to "none".
Add "tls-endpoint" binding type implementing "tls-server-end-point" from
RCF 5929, which is compatible with Windows.
Fix "tls-unique" to include the prefix in the bindings as per RFC 5056.
Always retry ldap_int_tls_connect() if it didn't complete,
regardless of blocking or non-blocking socket. Code from
ITS#7428 was wrong to only retry for async.
If multiple servers are specified, the connection to the first one
succeeds, and the hostname verification fails, *tls_session is not
dropped, but reused when connecting to the second server.
This is a problem with Mozilla NSS backend because another handshake
cannot be performed on the same file descriptor. From this reason,
hostname checking was moved into ldap_int_tls_connect() before
connection error handling.
Note: I could not test the MozNSS patch due to the absence of
NSS PEM support on my machine. Given the review comments in
https://bugzilla.mozilla.org/show_bug.cgi?id=402712 I doubt that
trustworthy PEM support will be appearing for MozNSS any time soon.
