Hi, I noticed that Net::LDAP doesn't seem to correctly verify the SSL certificate presented by a remote LDAP server, even if verify => 'require' is given when creating a connection, as in:
my $ldap = new Net::LDAP(
"ldaps://some.ldap.server",
version => 3,
verify => "require",
capath => "/etc/ssl/certs",
);
Specifically, Net::LDAP doesn't seem to attempt to verify the server's
identity -- as long as the server presents a certificate signed by a CA
that the client trusts, the client allows the connection to proceed.
This violates section 3.1.3 of RFC 4513, which describes how LDAP
clients should validate SSL certificates, and, IIUC, effectively allows
anyone with an SSL certificate for any site signed by a widely-trusted
CA to successfully impersonate, from the perspective of Net::LDAP
clients, any LDAP server, even if those clients are configured to
strictly validate server certificates.
This behavior seems to be a result of IO::Socket::SSL's default behavior
regarding identity verification, which is to not validate identities:
SSL_verifycn_scheme
Set the scheme used to automatically verify the hostname of the
peer. See the information about the verification schemes in
verify_hostname. The default is undef, e.g. to not automatically
verify the hostname.
(from http://search.cpan.org/~sullr/IO-Socket-SSL-1.44/SSL.pm)
We can easily address this by changing the options we pass to
IO::Socket::SSL's new and start_SSL functions. I'm attaching a patch
that does this, setting SSL_verifycn_name to 'ldap'. This behaves
correctly in my tests: LDAPS connections to a server only succeed if the
server presents a certificate (signed by a CA trusted by the client)
that correctly identifies the name that the client connected to.
Any thoughts? Does this seem appropriate for inclusion in a future
release of the perl-ldap software?
Thanks,
--
Kevan Carstensen <kacarsten...@csupomona.edu>
Operating Systems Analyst, I&IT Systems, Cal Poly Pomona
specify-verifycn-scheme.patch
Description: Binary data
