1Net::LDAP::Security(3)User Contributed Perl DocumentationNet::LDAP::Security(3)
2
6 Net::LDAP::Security - Security issues with LDAP connections
7
9 none
10
12 This document discusses various security issues relating to using LDAP
13 and connecting to LDAP servers, notably how to manage these potential
14 vulnerabilities:
15 · do you know that you are connected to the right server
17 · can someone sniff your passwords/userids from the directory connec‐
19 tion
20 · can someone sniff other confidential information from the directory
22 connection
23 Net::LDAP provides ways to address these vulnerabilities: through the
25 use of LDAPS, or LDAPv3 and TLS, and/or the use of SASL. Each of these
26 will be explained below.
27 How does an LDAP connection work
29 A normal LDAPv2 or LDAPv3 connection works by the client connecting
31 directly to port 389 (by default), and then issuing various LDAP
32 requests like search, add, etc.
33 There is no way to guarantee that an LDAP client is connected to the
35 right LDAP server. Hackers could have poisoned your DNS, so 'ldap.exam‐
36 ple.com' could be made to point to 'ldap.hacker.com'. Or they could
37 have installed their own server on the correct machine.
38 It is in the nature of the LDAP protocol that all information goes
40 between the client and the server in 'plain text'. This is a term used
41 by cryptographers to describe unencrypted and recoverable data, so even
42 though LDAP can transfer binary values like JPEG photographs, audio
43 clips and X.509 certificates, everything is still considered 'plain
44 text'.
45 If these vulnerabilities are an issue to, then you should consider the
47 other possibilities described below, namely LDAPS, LDAPv3 and TLS, and
48 SASL.
49 How does an LDAPS connection work
51 LDAPS is an unofficial protocol. It is to LDAP what HTTPS is to HTTP,
53 namely the exact same protocol (but in this case LDAPv2 or LDAPv3) run‐
54 ning over a secured SSL ("Secure Socket Layer") connection to port 636
55 (by default).
56 Not all servers will be configured to listen for LDAPS connections, but
58 if they do, it will commonly be on a different port from the normal
59 plain text LDAP port.
60 Using LDAPS can potentially solve the vulnerabilities described above,
62 but you should be aware that simply "using" SSL is not a magic bullet
63 that automatically makes your system "secure".
64 First of all, LDAPS can solve the problem of verifying that you are
66 connected to the correct server. When the client and server connect,
67 they perform a special SSL 'handshake', part of which involves the
68 server and client exchanging cryptographic keys, which are described
69 using X.509 certificates. If the client wishes to confirm that it is
70 connected to the correct server, all it needs to do is verify the
71 server's certificate which is sent in the handshake. This is done in
72 two ways:
73 1 check that the certificate is signed (trusted) by someone that you
75 trust, and that the certificate hasn't been revoked. For instance,
76 the server's certificate may have been signed by Verisign
77 (www.verisign.com), and you decide that you want to trust Verisign
78 to sign legitimate certificates.
79 2 check that the least-significant cn RDN in the server's certifi‐
81 cate's DN is the fully-qualified hostname of the hostname that you
82 connected to when creating the LDAPS object. For example if the
83 server is <cn=ldap.example.com,ou=My department,o=My company>, then
84 the RDN to check is cn=ldap.example.com.
85 You can do this by using the cafile and capath options when creating a
87 Net::LDAPS object, and by setting the verify option to 'require'.
88 To prevent hackers 'sniffing' passwords and other information on your
90 connection, you also have to make sure the encryption algorithm used by
91 the SSL connection is good enough. This is also something that gets
92 decided by the SSL handshake - if the client and server cannot agree on
93 an acceptable algorithm the connection is not made.
94 Net::LDAPS will by default use all the algorithms built into your copy
96 of OpenSSL, except for ones considered to use "low" strength encryp‐
97 tion, and those using export strength encryption. You can override this
98 when you create the Net::LDAPS object using the 'ciphers' option.
99 Once you've made the secure connection, you should also check that the
101 encryption algorithm that is actually being used is one that you find
102 acceptable. Broken servers have been observed in the field which 'fail
103 over' and give you an unencrypted connection, so you ought to check for
104 that.
105 How does LDAP and TLS work
107 SSL is a good solution to many network security problems, but it is not
109 a standard. The IETF corrected some defects in the SSL mechanism and
110 published a standard called RFC 2246 which describes TLS ("Transport
111 Layer Security"), which is simply a cleaned up and standardized version
112 of SSL.
113 You can only use TLS with an LDAPv3 server. That is because the stan‐
115 dard (RFC 2830) for LDAP and TLS requires that the normal LDAP connec‐
116 tion (ie., on port 389) can be switched on demand from plain text into
117 a TLS connection. The switching mechanism uses a special extended LDAP
118 operation, and since these are not legal in LDAPv2, you can only switch
119 to TLS on an LDAPv3 connection.
120 So the way you use TLS with LDAPv3 is that you create your normal
122 LDAPv3 connection using "Net::LDAP::new()", and then you perform the
123 switch using "Net::LDAP::start_tls()". The "start_tls()" method takes
124 pretty much the same arguments as "Net::LDAPS::new()", so check above
125 for details.
126 How does SASL work
128 SASL is an authentication framework that can be used by a number of
130 different Internet services, including LDAPv3. Because it is only a
131 framework, it doesn't provide any way to authenticate by itself; to
132 actually authenticate to a service you need to use a specific SASL
133 mechanism. A number of mechanisms are defined, such as CRAM-MD5.
134 The use of a mechanism like CRAM-MD5 provides a solution to the pass‐
136 word sniffing vulnerability, because these mechanisms typically do not
137 require the user to send across a secret (eg., a password) in the clear
138 across the network. Instead, authentication is carried out in a clever
139 way which avoids this, and so prevents passwords from being sniffed.
140 Net::LDAP supports SASL using the Authen::SASL class. Currently the
142 only Authen::SASL subclasses (ie., SASL mechanism) available are
143 CRAM-MD5 and EXTERNAL.
144 Some SASL mechanisms provide a general solution to the sniffing of all
146 data on the network vulnerability, as they can negotiate confidential
147 (ie., encrypted) network connections. Note that this is over and above
148 any SSL or TLS encryption! Unfortunately, perl's Authen::SASL code can‐
149 not negotiate this.
150
152 Net::LDAP, Net::LDAPS, Authen::SASL
153
155 Jim Dutton <jimd@dutton3.it.siu.edu> provided lots of useful feedback
156 on the early drafts.
157
159 Chris Ridd <chris.ridd@isode.com>
160 Please report any bugs, or post any suggestions, to the perl-ldap mail‐
162 ing list <perl-ldap@perl.org>.
163
165 Copyright (c) 2001-2004 Chris Ridd. All rights reserved. This program
166 is free software; you can redistribute it and/or modify it under the
167 same terms as Perl itself.
168perl v5.8.8 2007-02-10 Net::LDAP::Security(3)