Bug #69871 for perl-ldap: LDAPS SSL validation

Thu Jul 28 19:30:25 2011 kacarstensen [...] csupomona.edu - Ticket created

Subject:	LDAPS SSL validation
Date:	Thu, 28 Jul 2011 16:30:13 -0700
To:	bug-perl-ldap [...] rt.cpan.org
From:	Kevan Carstensen <kacarstensen [...] csupomona.edu>

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 at all -- as long as the server presents a certificate signed by a CA that the client trusts, the client allows the connection to proceed. This is intuitively wrong, violates section 3.1.3 of RFC 4513, which describes how LDAP clients should validate SSL certificates, and 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 passed 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. Details about my setup: OS/platform: Linux hostname 2.6.37-gentoo-r4 #3 SMP Mon Jul 25 13:44:53 PDT 2011 x86_64 Intel(R) Xeon(TM) CPU 3.16GHz GenuineIntel GNU/Linux Perl version: This is perl 5, version 12, subversion 3 (v5.12.3) built for x86_64-linux (with 13 registered patches, see perl -V for more detail) Locally applied patches: 0001-gentoo_MakeMaker-RUNPATH.diff 0002-gentoo_config_over.diff 0003-gentoo_cpan_definstalldirs.diff 0004-gentoo_cpanplus_definstalldirs.diff 0005-gentoo_create-libperl-soname.diff 0006-gentoo_MakeMaker-delete_packlist.diff 0007-fixes_8d66b3f9_h2hp_fix.diff 0008-fixes_f178b03b_h2ph_using_deprecated_goto.diff 0009-gentoo_mod-paths.diff 0010-gentoo_enc2xs.diff 0011-gentoo_IO-Compress_AutoLoader_dropped_from_Compress-Zlib.diff 0012-gentoo_drop-fstack-protector.diff 0013-fixes_539689e74a_unwarrantedly_laundering_tainted_data.diff Package and version: perl-ldap-0.4001 Thanks, -- Kevan Carstensen <kacarstensen@csupomona.edu> Operating Systems Analyst, I&IT Systems, Cal Poly Pomona

Message body is not shown because sender requested not to inline it.

Thu Jul 28 20:52:47 2011 gbarr [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #69871] LDAPS SSL validation
Date:	Thu, 28 Jul 2011 19:52:37 -0500
To:	"bug-perl-ldap [...] rt.cpan.org" <bug-perl-ldap [...] rt.cpan.org>
From:	Graham Barr <gbarr [...] pobox.com>

I do not consider myself an expert with SSL options. As such most code in Net::LDAP for SSL has been contributed by others. So before I apply such a patch please consider posting your patch and reasons to the Perl-ldap mailing list. iGraham.

Thu Jul 28 20:52:48 2011 The RT System itself - Status changed from 'new' to 'open'

Tue Aug 09 19:21:28 2011 kacarstensen [...] csupomona.edu - Correspondence added

Subject:	Re: [rt.cpan.org #69871] LDAPS SSL validation
Date:	Tue, 09 Aug 2011 16:21:16 -0700
To:	"bug-perl-ldap [...] rt.cpan.org" <bug-perl-ldap [...] rt.cpan.org>
From:	Kevan Carstensen <kacarstensen [...] csupomona.edu>

Excerpts from Graham Barr via RT's message of 2011-07-28 17:52:48 -0700: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=69871 > > > I do not consider myself an expert with SSL options. As such most code > in Net::LDAP for SSL has been contributed by others. So before I apply > such a patch please consider posting your patch and reasons to the > Perl-ldap mailing list.

You can see the discussion thread at [1]. I've attached a copy of the patch referenced in [2] to this message so it'll show up on the bug. It still needs a Changes entry. I'm not sure if you prefer to write those yourself; if not, I can handle it. Do you think that's enough feedback, or would you prefer to wait a little bit longer to see if any more comments come out of the woodwork? [1] http://www.nntp.perl.org/group/perl.ldap/2011/08/msg3530.html [2] http://www.nntp.perl.org/group/perl.ldap/2011/08/msg3533.html Thanks, -- Kevan Carstensen <kacarstensen@csupomona.edu> Operating Systems Analyst, I&IT Systems, Cal Poly Pomona

Message body is not shown because sender requested not to inline it.

Fri Sep 02 19:18:16 2011 kacarstensen [...] csupomona.edu - Correspondence added

Subject:	Re: [rt.cpan.org #69871] LDAPS SSL validation
Date:	Fri, 02 Sep 2011 16:18:07 -0700
To:	"bug-perl-ldap [...] rt.cpan.org" <bug-perl-ldap [...] rt.cpan.org>
From:	Kevan Carstensen <kacarstensen [...] csupomona.edu>

Ping. Any movement on getting these changes merged into perl-ldap? Thanks, -- Kevan Carstensen <kacarstensen@csupomona.edu> Operating Systems Analyst, I&IT Systems, Cal Poly Pomona

Sat Sep 03 08:51:22 2011 gbarr [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #69871] LDAPS SSL validation
Date:	Sat, 3 Sep 2011 07:51:06 -0500
To:	bug-perl-ldap [...] rt.cpan.org
From:	Graham Barr <gbarr [...] pobox.com>

Sorry, I dropped the ball on this. 0.42 has been release to CPAN including this pathc Thanks, Graham.

Tue Sep 06 12:05:24 2011 kacarstensen [...] csupomona.edu - Correspondence added

Subject:	Re: [rt.cpan.org #69871] LDAPS SSL validation
Date:	Tue, 06 Sep 2011 09:05:15 -0700
To:	"bug-perl-ldap [...] rt.cpan.org" <bug-perl-ldap [...] rt.cpan.org>
From:	Kevan Carstensen <kacarstensen [...] csupomona.edu>

Excerpts from Graham Barr via RT's message of 2011-09-03 05:51:23 -0700: Show quoted text

> Sorry, I dropped the ball on this. 0.42 has been release to CPAN > including this pathc

No worries. Thanks for releasing the new version. :-) -- Kevan Carstensen <kacarstensen@csupomona.edu> Operating Systems Analyst, I&IT Systems, Cal Poly Pomona

Sun Jan 29 14:25:33 2012 MARSCHAP [...] cpan.org - Correspondence added

On Tue Sep 06 12:05:24 2011, kacarstensen@csupomona.edu wrote: Show quoted text

> Excerpts from Graham Barr via RT's message of 2011-09-03 05:51:23

-0700: Show quoted text

> > Sorry, I dropped the ball on this. 0.42 has been release to CPAN > > including this pathc

> > No worries. Thanks for releasing the new version. :-)

Now that 0.44 has been released with changes in that region, can you give it a try, test whether it fixes the issue and report back? Thanks Peter

Mon Feb 13 12:48:01 2012 Sam.Patterson [...] nau.edu - Correspondence added

Subject:	Re: [rt.cpan.org #69871] LDAPS SSL validation
Date:	Mon, 13 Feb 2012 17:47:39 +0000
To:	"bug-perl-ldap [...] rt.cpan.org" <bug-perl-ldap [...] rt.cpan.org>
From:	Samuel Trever Patterson <Sam.Patterson [...] nau.edu>

Peter, We were also seeing problems with certificate validation with Net::LDAP version 0.44. Using the "start_tls" method the only time we see any error at all is using the 'cafile' argument and pointing to a file that does not exist. If the file exists at all (even containing a totally non-matching certificate) the TLS connection succeeds. The 'capath' argument always results in a successful TLS connection, even if the directory does not exist, exists and has no certs in it, or even if it exists and has the wrong certs in it. In these tests Perl was version 5.14.2 and IO::Socket::SSL was version 1.54. This was running on 2.6.18-238.9.1.el5. Regards, Sam -- Samuel T. Patterson Systems Administrator-Senior Northern Arizona University Information Technology Services 1300 S. Knoles Dr. Flagstaff, AZ 86011 928-523-1880 Sam.Patterson@nau.edu

Sat Feb 18 09:49:56 2012 MARSCHAP [...] cpan.org - Correspondence added

Subject:

LDAPS SSL validation - cannot reproduce

Hi, On Mon Feb 13 12:48:01 2012, Sam.Patterson@nau.edu wrote: Show quoted text

> We were also seeing problems with certificate validation with > Net::LDAP version 0.44. > > Using the "start_tls" method the only time we see any error at all is > using the 'cafile' argument and pointing to a file that does not > exist. If the file exists at all (even containing a totally non- > matching certificate) the TLS connection succeeds. The 'capath' > argument always results in a successful TLS connection, even if the > directory does not exist, exists and has no certs in it, or even if > it exists and has the wrong certs in it. > > In these tests Perl was version 5.14.2 and IO::Socket::SSL was version > 1.54. This was running on 2.6.18-238.9.1.el5.

Strange, I cannot reproduce it. Using the same Perl and IO::Socket::SSL version that you use, the following simple test script: #!/usr/bin/perl -W use Net::LDAP; use Data::Dumper; my $ldap = new Net::LDAP($ARGV[0]) or die "$@"; my $mesg = $ldap->start_tls(verify => "require", cafile => $ARGV[1], capath => $ARGV[2]); print Dumper(\$mesg); dumps a successfully encrypted session only when * either 'cafile' is set to a non-empty value that contains the filename of the certificate of the root CA that issued the server's certificate * or 'capath' is set to a non-empty value and set to a path that contains the c_rehash'ed root CA certificate issuing the server's sertificate In all other cases I tested (e.g. 'cafile' not pointing to the root CA of the server's cert or 'capath' not containing the file of the server's root CA) the script dumped an unsuccessful start_tls operation. Best Peter

Fri Feb 24 12:14:20 2012 Sam.Patterson [...] nau.edu - Correspondence added

Subject:	Re: [rt.cpan.org #69871] LDAPS SSL validation
Date:	Fri, 24 Feb 2012 17:14:06 +0000
To:	"<bug-perl-ldap [...] rt.cpan.org>" <bug-perl-ldap [...] rt.cpan.org>
From:	Samuel Trever Patterson <Sam.Patterson [...] nau.edu>

Peter, Thanks for getting back to me. I used your code snip and still got those odd results… it looks like the problem is not with Net::LDAP! I thought it might have something to do my testing platform and started doing all sorts of tests in various places. As far as I was able to determine, this is really an issue with Net::SSLeay and OpenSSL. Net::SSLeay built with version OpenSSL 1.0.0x worked as expected, but Net::SSLeay using OpenSSL version 0.9.8x displayed this odd behavior. (In fact, this 0.9.8x I seem to get a working object in the dump if I used _any_ valid certificate or certificate chain. I only get an error if there were no certificates or the certificate I pointed at was not a real certificate but some random text.) I used ldd to (really) see where each SSLeay.so was getting its OpenSSL libraries from. Here's what I found. These combinations of software/module failed my tests: - RHEL 5 Linux with perl 5.8.9, Net::LDAP 0.44, IO::Socket::SSL 1.55, Net::SSLeay 1.42, OpenSSL 0.9.8r - RHEL 5 Linux with perl 5.12.1, Net::LDAP 0.4001, IO::Socket::SSL 1.33, Net::SSLeay 1.36, OpenSSL 0.9.8o - OS X with perl 5.12.3, Net::LDAP .04001, IO::Socket::SSL 1.35, Net::SSLeay 1.36, OpenSSL 0.9.8r (This is all the OS X delivered stuff.) And these succeeded at validating a cert and acted as expected: - RHEL 5 Linux with perl 5.8.9, Net::LDAP 0.44, IO::Socket::SSL 1.55, Net::SSLeay 1.42, OpenSSL 1.0.0g - RHEL 5 Linux with perl 5.14.2, Net::LDAP 0.44, IO::Socket::SSL 1.55, Net::SSLeay 1.42, OpenSSL 1.0.0g - RHEL 6 Linux with perl 5.14.2, Net::LDAP 0.44, IO::Socket::SSL 1.55, Net::SSLeay 1.42, OpenSSL 1.0.0e - RHEL 6 Linux with perl 5.12.4, Net::LDAP 0.4001, IO::Socket::SSL 1.44, Net::SSLeay 1.36, OpenSSL 1.0.0d - RHEL 6 Linux with perl 5.8.9, Net::LDAP 0.4001, IO::Socket::SSL 1.44, Net::SSLeay 1.36, OpenSSL 1.0.0-fips The other problem (and this took a while to find) was that when building Net::SSLeay, if there is a default version of OpenSSL delivered with your Linux distro and you then build your own, more up-to-date version of OpenSSL, the makefile for Net::SSLeay will end up finding the distro-delivered libraries first and using them instead of the version you asked for. (This makes what is really built for Net::SSLeay a bit unpredictable despite what the Makefile.PL prints to the screen…) This is why building Net::SSLeay fails to work sometimes… the headers and libraries may be from totally different versions of OpenSSL. It seems to be a matter of the "-L"s the makefile sends to the complier/linker. I'll submit a bug for the Net::SSLeay issue. I do appreciate all of your time and help! Regards, Sam

Thu May 17 12:30:32 2012 MARSCHAP [...] cpan.org - Status changed from 'open' to 'rejected'