Net::LDAP::Security - phpMan

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

SYNOPSIS
      none

DESCRIPTION
    This document discusses various security issues relating to using LDAP
    and connecting to LDAP 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 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
    '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'.

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

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

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

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

SEE ALSO
    Net::LDAP, Net::LDAPS, Authen::SASL

ACKNOWLEDGEMENTS
    Jim Dutton <jimd AT dutton3.edu> provided lots of useful feedback on
    the early drafts.

AUTHOR
    Chris Ridd <chris.ridd AT isode.com>

    Please report any bugs, or post any suggestions, to the perl-ldap
    mailing list <perl-ldap AT 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.