Net::LDAP::Security (3)

Leading comments

Automatically generated by Pod::Man 2.28 (Pod::Simple 3.28)

Standard preamble:
========================================================================

(The comments found at the beginning of the groff file "man3/Net::LDAP::Security.3pm".)

NAME

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

SYNOPSIS

  none

DESCRIPTION

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

*

do you know that you are connected to the right server

*

can someone sniff your passwords/userids from the directory connection

*

can someone sniff other confidential information from the directory connection

Net::LDAP provides ways to address these vulnerabilities: through the use of

or LDAPv3 and and/or the use of 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 requests like search, add, etc.

There is no way to guarantee that an

client is connected to the right server. Hackers could have poisoned your 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

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 can transfer binary values like photographs, audio clips and X.509 certificates, everything is still considered 'plain text'.

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

LDAPv3 and and

How does an

LDAPS

connection work

is an unofficial protocol. It is to what is to namely the exact same protocol (but in this case LDAPv2 or LDAPv3) running over a secured (``Secure Socket Layer'') connection to port 636 (by default).

Not all servers will be configured to listen for

connections, but if they do, it will commonly be on a different port from the normal plain text port.

Using

can potentially solve the vulnerabilities described above, but you should be aware that simply ``using'' is not a magic bullet that automatically makes your system ``secure''.

First of all,

can solve the problem of verifying that you are connected to the correct server. When the client and server connect, they perform a special '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 (www.verisign.com), 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 <cn=ldap.example.com,ou=My department,o=My company>, then the

RDN

to check is cn=ldap.example.com.

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

connection is good enough. This is also something that gets decided by the 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.

How does

LDAP

and

TLS

work

is a good solution to many network security problems, but it is not a standard. The corrected some defects in the mechanism and published a standard called which describes (``Transport Layer Security''), which is simply a cleaned up and standardized version of

You can only use

with an LDAPv3 server. That is because the standard () for and requires that the normal connection (ie., on port 389) can be switched on demand from plain text into a connection. The switching mechanism uses a special extended operation, and since these are not legal in LDAPv2, you can only switch to on an LDAPv3 connection.

So the way you use

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

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 mechanism. A number of mechanisms are defined, such as

The use of a mechanism like

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 sniffed.

Net::LDAP supports

using the Authen::SASL class. Currently the only Authen::SASL subclasses (ie., mechanism) available are and

Some

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 or encryption! Unfortunately, perl's Authen::SASL code cannot negotiate this.

SEE ALSO

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

ACKNOWLEDGEMENTS

Jim Dutton <jimd@dutton3.it.siu.edu> provided lots of useful feedback on the early drafts.

AUTHOR

Chris Ridd <chris.ridd@isode.com>

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

COPYRIGHT

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.