> Is LDAPS just regular LDAP running on top of SSL/TLS, in the same way
as HTTPS is to HTTP? Or is it like the FTP with the --ftp-ssl option or
SSL telnet where an LDAP negotiation takes place before SSL is enabled?

Much like FTP. From what I read, LDAPS is non-standard, behaves like
FTPS or HTTPS, on a different port than LDAP. Standard encryption scheme
for LDAP is on the regular LDAP port, with a StartTLS command like for
--ftp-ssl. I can imagine OpenLDAP does it the later way. I really don't
know for Win$ or CLDAP SDK.

> If the former, then surely we can use libcurl's already portable SSL
back-end components to negotiate SSL over the socket before handing it
to OpenLDAP to do the LDAP stuff.

Definitely not, because we never deal with a socket when using a library
like libldap.so or winldap32.dll or etc.

> I suspect that using the LDAP library's LDAPS support will introduce
problems when LDAP is compiled to use one SSL library (e.g. OpenSSL)
while libcurl is compiled to use another (e.g. yaSSL), with symbol
clashes, etc.

Might be :-(
That's why I talked first about zapping the external LDAP library use
and dealing directly with the LDAP protocol at the socket level
(preferably having the multi interface in mind!). First, this will
resolve incompatibilities at the LDAP level, because they are already
resolved for the sockets. Then, we can talk about reusing our SSL code
much like for FTPto implement both LDAPS and LDAP/TLS support, and even
think about uploading LDAP data. The code will be much larger, but we'll
have less conditionals and less compatibility problems.

But who has the time and mood to rewrite it ? ;-|
Received on 2007-08-16