{ "content": [ { "type": "text", "text": "# Net::LDAP::Security (perldoc)\n\n## NAME\n\nNet::LDAP::Security - Security issues with LDAP connections\n\n## SYNOPSIS\n\nnone\n\n## DESCRIPTION\n\nThis document discusses various security issues relating to using LDAP and connecting to LDAP\nservers, notably how to manage these potential vulnerabilities:\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION** (4 subsections)\n- **SEE ALSO**\n- **ACKNOWLEDGEMENTS**\n- **AUTHOR**\n- **COPYRIGHT**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "Net::LDAP::Security", "section": "", "mode": "perldoc", "summary": "Net::LDAP::Security - Security issues with LDAP connections", "synopsis": "none", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 2, "subsections": [] }, { "name": "DESCRIPTION", "lines": 12, "subsections": [ { "name": "How does an LDAP connection work", "lines": 15 }, { "name": "How does an LDAPS connection work", "lines": 43 }, { "name": "How does LDAP and TLS work", "lines": 16 }, { "name": "How does SASL work", "lines": 18 } ] }, { "name": "SEE ALSO", "lines": 2, "subsections": [] }, { "name": "ACKNOWLEDGEMENTS", "lines": 2, "subsections": [] }, { "name": "AUTHOR", "lines": 5, "subsections": [] }, { "name": "COPYRIGHT", "lines": 3, "subsections": [] } ], "sections": { "NAME": { "content": "Net::LDAP::Security - Security issues with LDAP connections\n", "subsections": [] }, "SYNOPSIS": { "content": "none\n", "subsections": [] }, "DESCRIPTION": { "content": "This document discusses various security issues relating to using LDAP and connecting to LDAP\nservers, notably how to manage these potential vulnerabilities:\n\n* do you know that you are connected to the right server\n\n* can someone sniff your passwords/userids from the directory connection\n\n* can someone sniff other confidential information from the directory connection\n\nNet::LDAP provides ways to address these vulnerabilities: through the use of LDAPS, or LDAPv3\nand TLS, and/or the use of SASL. Each of these will be explained below.\n", "subsections": [ { "name": "How does an LDAP connection work", "content": "A normal LDAPv2 or LDAPv3 connection works by the client connecting directly to port 389 (by\ndefault), and then issuing various LDAP requests like search, add, etc.\n\nThere is no way to guarantee that an LDAP client is connected to the right LDAP server. Hackers\ncould have poisoned your DNS, so 'ldap.example.com' could be made to point to 'ldap.hacker.com'.\nOr they could have installed their own server on the correct machine.\n\nIt is in the nature of the LDAP protocol that all information goes between the client and the\nserver in 'plain text'. This is a term used by cryptographers to describe unencrypted and\nrecoverable data, so even though LDAP can transfer binary values like JPEG photographs, audio\nclips and X.509 certificates, everything is still considered 'plain text'.\n\nIf these vulnerabilities are an issue to, then you should consider the other possibilities\ndescribed below, namely LDAPS, LDAPv3 and TLS, and SASL.\n" }, { "name": "How does an LDAPS connection work", "content": "LDAPS is an unofficial protocol. It is to LDAP what HTTPS is to HTTP, namely the exact same\nprotocol (but in this case LDAPv2 or LDAPv3) running over a *secured* SSL (\"Secure Socket\nLayer\") connection to port 636 (by default).\n\nNot all servers will be configured to listen for LDAPS connections, but if they do, it will\ncommonly be on a different port from the normal plain text LDAP port.\n\nUsing LDAPS can *potentially* solve the vulnerabilities described above, but you should be aware\nthat simply \"using\" SSL is not a magic bullet that automatically makes your system \"secure\".\n\nFirst of all, LDAPS can solve the problem of verifying that you are connected to the correct\nserver. When the client and server connect, they perform a special SSL 'handshake', part of\nwhich involves the server and client exchanging cryptographic keys, which are described using\nX.509 certificates. If the client wishes to confirm that it is connected to the correct server,\nall it needs to do is verify the server's certificate which is sent in the handshake. This is\ndone in two ways:\n\n1 check that the certificate is signed (trusted) by someone that you trust, and that the\ncertificate hasn't been revoked. For instance, the server's certificate may have been signed\nby Verisign (www.verisign.com), and you decide that you want to trust Verisign to sign\nlegitimate certificates.\n\n2 check that the least-significant cn RDN in the server's certificate's DN is the\nfully-qualified hostname of the hostname that you connected to when creating the LDAPS\nobject. For example if the server is ,\nthen the RDN to check is cn=ldap.example.com.\n\nYou can do this by using the cafile and capath options when creating a Net::LDAPS object, *and*\nby setting the verify option to 'require'.\n\nTo prevent hackers 'sniffing' passwords and other information on your connection, you also have\nto make sure the encryption algorithm used by the SSL connection is good enough. This is also\nsomething that gets decided by the SSL handshake - if the client and server cannot agree on an\nacceptable algorithm the connection is not made.\n\nNet::LDAPS will by default use all the algorithms built into your copy of OpenSSL, except for\nones considered to use \"low\" strength encryption, and those using export strength encryption.\nYou can override this when you create the Net::LDAPS object using the 'ciphers' option.\n\nOnce you've made the secure connection, you should also check that the encryption algorithm that\nis actually being used is one that you find acceptable. Broken servers have been observed in the\nfield which 'fail over' and give you an unencrypted connection, so you ought to check for that.\n" }, { "name": "How does LDAP and TLS work", "content": "SSL is a good solution to many network security problems, but it is not a standard. The IETF\ncorrected some defects in the SSL mechanism and published a standard called RFC 2246 which\ndescribes TLS (\"Transport Layer Security\"), which is simply a cleaned up and standardized\nversion of SSL.\n\nYou can only use TLS with an LDAPv3 server. That is because the standard (RFC 4511) for LDAP and\nTLS requires that the *normal* LDAP connection (i.e., on port 389) can be switched on demand\nfrom plain text into a TLS connection. The switching mechanism uses a special extended LDAP\noperation, and since these are not legal in LDAPv2, you can only switch to TLS on an LDAPv3\nconnection.\n\nSo the way you use TLS with LDAPv3 is that you create your normal LDAPv3 connection using\n\"Net::LDAP::new()\", and then you perform the switch using \"Net::LDAP::starttls()\". The\n\"starttls()\" method takes pretty much the same arguments as \"Net::LDAPS::new()\", so check above\nfor details.\n" }, { "name": "How does SASL work", "content": "SASL is an authentication framework that can be used by a number of different Internet services,\nincluding LDAPv3. Because it is only a framework, it doesn't provide any way to authenticate by\nitself; to actually authenticate to a service you need to use a specific SASL *mechanism*. A\nnumber of mechanisms are defined, such as CRAM-MD5.\n\nThe use of a mechanism like CRAM-MD5 provides a solution to the password sniffing vulnerability,\nbecause these mechanisms typically do not require the user to send across a secret (e.g., a\npassword) in the clear across the network. Instead, authentication is carried out in a clever\nway which avoids this, and so prevents passwords from being sniffed.\n\nNet::LDAP supports SASL using the Authen::SASL class. Currently the only Authen::SASL subclasses\n(i.e., SASL mechanism) available are CRAM-MD5 and EXTERNAL.\n\nSome SASL mechanisms provide a general solution to the sniffing of all data on the network\nvulnerability, as they can negotiate confidential (i.e., encrypted) network connections. Note\nthat this is over and above any SSL or TLS encryption! Unfortunately, perl's Authen::SASL code\ncannot negotiate this.\n" } ] }, "SEE ALSO": { "content": "Net::LDAP, Net::LDAPS, Authen::SASL\n", "subsections": [] }, "ACKNOWLEDGEMENTS": { "content": "Jim Dutton provided lots of useful feedback on the early drafts.\n", "subsections": [] }, "AUTHOR": { "content": "Chris Ridd \n\nPlease report any bugs, or post any suggestions, to the perl-ldap mailing list\n.\n", "subsections": [] }, "COPYRIGHT": { "content": "Copyright (c) 2001-2004 Chris Ridd. All rights reserved. This program is free software; you can\nredistribute it and/or modify it under the same terms as Perl itself.\n", "subsections": [] } } } }