There is no way to guarantee that an LDAP client is connected to the right LDAP server. Hackers could have poisoned your DNS, so 'ldap.example.com' could be made to point to 'ldap.hacker.com'. Or they could have installed their own server on the correct machine.
It is in the nature of the LDAP protocol that all information goes between the client and the server in 'plain text'. This is a term used by cryptographers to describe unencrypted and recoverable data, so even though LDAP can transfer binary values like JPEG photographs, audio clips and X.509 certificates, everything is still considered 'plain text'.
Not all servers will be configured to listen for LDAPS connections, but if they do, it will commonly be on a different port from the normal plain text LDAP port.
Using LDAPS can potentially solve the vulnerabilities described above, but you should be aware that simply ``using'' SSL is not a magic bullet that automatically makes your system ``secure''.
First of all, LDAPS can solve the problem of verifying that you are connected to the correct server. When the client and server connect, they perform a special SSL 'handshake', part of which involves the server and client exchanging cryptographic keys, which are described using X.509 certificates. If the client wishes to confirm that it is connected to the correct server, all it needs to do is verify the server's certificate which is sent in the handshake. This is done in two ways:
You can do this by using the cafile and capath options when creating a Net::LDAPS object, and by setting the verify option to 'require'.
To prevent hackers 'sniffing' passwords and other information on your connection, you also have to make sure the encryption algorithm used by the SSL connection is good enough. This is also something that gets decided by the SSL handshake - if the client and server cannot agree on an acceptable algorithm the connection is not made.
Net::LDAPS will by default use all the algorithms built into your copy of OpenSSL, except for ones considered to use ``low'' strength encryption, and those using export strength encryption. You can override this when you create the Net::LDAPS object using the 'ciphers' option.
Once you've made the secure connection, you should also check that the encryption algorithm that is actually being used is one that you find acceptable. Broken servers have been observed in the field which 'fail over' and give you an unencrypted connection, so you ought to check for that.
You can only use TLS with an LDAPv3 server. That is because the standard (RFC 4511) for LDAP and TLS requires that the normal LDAP connection (i.e., on port 389) can be switched on demand from plain text into a TLS connection. The switching mechanism uses a special extended LDAP operation, and since these are not legal in LDAPv2, you can only switch to TLS on an LDAPv3 connection.
So the way you use TLS with LDAPv3 is that you create your normal LDAPv3 connection using "Net::LDAP::new()", and then you perform the switch using "Net::LDAP::start_tls()". The "start_tls()" method takes pretty much the same arguments as "Net::LDAPS::new()", so check above for details.
The use of a mechanism like CRAM-MD5 provides a solution to the password sniffing vulnerability, because these mechanisms typically do not require the user to send across a secret (e.g., a password) in the clear across the network. Instead, authentication is carried out in a clever way which avoids this, and so prevents passwords from being sniffed.
Net::LDAP supports SASL using the Authen::SASL class. Currently the only Authen::SASL subclasses (i.e., SASL mechanism) available are CRAM-MD5 and EXTERNAL.
Some SASL mechanisms provide a general solution to the sniffing of all data on the network vulnerability, as they can negotiate confidential (i.e., encrypted) network connections. Note that this is over and above any SSL or TLS encryption! Unfortunately, perl's Authen::SASL code cannot negotiate this.
Please report any bugs, or post any suggestions, to the perl-ldap mailing list <email@example.com>.