Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
Net::LDAP::Security(3)User Contributed Perl DocumentatioNet::LDAP::Security(3)

       Net::LDAP::Security - Security issues with LDAP connections


       This document discusses various security	issues relating	to using LDAP
       and connecting to LDAP servers, notably how to manage these potential

       o   do you know that you	are connected to the right server

       o   can someone sniff your passwords/userids from the directory

       o   can someone sniff other confidential	information from the directory

       Net::LDAP provides ways to address these	vulnerabilities: through the
       use of LDAPS, or	LDAPv3 and TLS,	and/or the use of SASL.	Each of	these
       will be explained below.

   How does an LDAP connection work
       A normal	LDAPv2 or LDAPv3 connection works by the client	connecting
       directly	to port	389 (by	default), and then issuing various LDAP
       requests	like search, add, etc.

       There is	no way to guarantee that an LDAP client	is connected to	the
       right LDAP server. Hackers could	have poisoned your DNS,	so
       '' could	be made	to point to ''. 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

       If these	vulnerabilities	are an issue to, then you should consider the
       other possibilities described below, namely LDAPS, LDAPv3 and TLS, and

   How does an LDAPS connection	work
       LDAPS is	an unofficial protocol.	It is to LDAP what HTTPS is to HTTP,
       namely the exact	same protocol (but in this case	LDAPv2 or LDAPv3)
       running over a secured SSL ("Secure Socket Layer") connection to	port
       636 (by default).

       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:

       1.  check that the certificate is signed	(trusted) by someone that you
	   trust, and that the certificate hasn't been revoked.	For instance,
	   the server's	certificate may	have been signed by Verisign
	   (, and you decide that you want to trust Verisign
	   to sign legitimate certificates.

       2.  check that the least-significant cn RDN in the server's
	   certificate's DN is the fully-qualified hostname of the hostname
	   that	you connected to when creating the LDAPS object. For example
	   if the server is <,ou=My department,o=My
	   company>, then the RDN to check is

       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'

       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

   How does LDAP and TLS work
       SSL is a	good solution to many network security problems, but it	is not
       a standard. The IETF corrected some defects in the SSL mechanism	and
       published a standard called RFC 2246 which describes TLS	("Transport
       Layer Security"), which is simply a cleaned up and standardized version
       of SSL.

       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 (ie.,	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.

   How does SASL work
       SASL is an authentication framework that	can be used by a number	of
       different Internet services, including LDAPv3. Because it is only a
       framework, it doesn't provide any way to	authenticate by	itself;	to
       actually	authenticate to	a service you need to use a specific SASL
       mechanism. A number of mechanisms are defined, such as CRAM-MD5.

       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 (eg., 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

       Net::LDAP supports SASL using the Authen::SASL class. Currently the
       only Authen::SASL subclasses (ie., 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
       (ie., encrypted)	network	connections. Note that this is over and	above
       any SSL or TLS encryption! Unfortunately, perl's	Authen::SASL code
       cannot negotiate	this.

       Net::LDAP, Net::LDAPS, Authen::SASL

       Jim Dutton <> provided lots of useful feedback
       on the early drafts.

       Chris Ridd <>

       Please report any bugs, or post any suggestions,	to the perl-ldap
       mailing list <>.

       Copyright (c) 2001-2004 Chris Ridd. All rights reserved.	This program
       is free software; you can redistribute it and/or	modify it under	the
       same terms as Perl itself.

perl v5.32.0			  2015-04-02		Net::LDAP::Security(3)


Want to link to this manual page? Use this URL:

home | help