Bug #99910 for IO-Socket-SSL: possible bug/issue in IO::Socket::SSL v1.94

Thu Oct 30 12:08:19 2014 brian.biggs [...] sonoma.edu - Ticket created

Subject:	possible bug/issue in IO::Socket::SSL v1.94
Date:	Thu, 30 Oct 2014 09:08:00 -0700
To:	<bug-IO-Socket-SSL [...] rt.cpan.org>
From:	Brian Biggs <brian.biggs [...] sonoma.edu>

Hi, I've run into an issue where it seems that the use of certain global variables in IO::Socket::SSL have caused failures under certain circumstances. Specifically when a second SSL connection is made within the same program to a different host with a different SSL cert. I was able to mitigate the problem by clearing the globals like this: # Call this to mitigate a bug in IO::Socket::SSL which has some # global settings that don't get cleaned up between connections. # We also check for set_defaults() because the RHEL6 version of # IO::Socket::SSL doesn't have a set_defaults() function. defined(&IO::Socket::SSL::set_defaults) && IO::Socket::SSL::set_defaults( verifycn_name => undef, SSL_verifycn_name => undef, SSL_verifycn_scheme => undef, SSL_verify_mode => undef ); This program (a CGI) first makes a connection to LDAP and then makes a call to CAS to authenticate a user. This program is running fine on a RHEL6 distro using the following versions: perl v5.10.1 IO::Socket::SSL v1.31 Linux redacted_name 2.6.32-431.29.2.el6.x86_64 #1 SMP Sun Jul 27 15:55:46 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux Migrating to RHEL7 caused this problem to exhibit. Our RHEL7 environment has the following versions: perl v5.16.3 IO::Socket::SSL v1.94 Linux redacted_name 3.10.0-123.8.1.el7.x86_64 #1 SMP Mon Aug 11 13:37:49 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux The error message we received when we migrated to RHEL7 was: Not a GLOB reference at /usr/share/perl5/vendor_perl/IO/Socket/SSL.pm line 1377 With the mitigation code in place we see the following issues in the web server logs: Use of uninitialized value $verify_mode in numeric ne (!=) at /usr/share/perl5/vendor_perl/IO/Socket/SSL.pm line 1649 and Use of uninitialized value in subroutine entry at /usr/share/perl5/vendor_perl/IO/Socket/SSL.pm line 1776 but the code runs successfully. If this is not a bug/issue with IO::Socket::SSL I do apologize. -Brian -- Brian Biggs Sonoma State University

Thu Oct 30 13:19:42 2014 Steffen_Ullrich [...] genua.de - Correspondence added

Hi Brian, the release of 1.94 was 06/2013. Since then 50 new versions were released. Please understand that I will not put too much effort into supporting such old versions. But of course I will look into the issue to see if it applies to current versions too. Show quoted text

> I've run into an issue where it seems that the use of certain global > variables in IO::Socket::SSL have caused failures under certain > circumstances. Specifically when a second SSL connection is made within > the same program to a different host with a different SSL cert.

Unfortunately this report does not contain enough information to reproduce the problem. Having multiple connections with different certificates at the same time is definitely supported, but there are issues when using threads. Please provide a test program or description, which is as simple as possible but clear enough to make the issue reproducible. Show quoted text

> I was able to mitigate the problem by clearing the globals like this: > > # Call this to mitigate a bug in IO::Socket::SSL which has some > # global settings that don't get cleaned up between connections. > # We also check for set_defaults() because the RHEL6 version of > # IO::Socket::SSL doesn't have a set_defaults() function. > defined(&IO::Socket::SSL::set_defaults) && > IO::Socket::SSL::set_defaults( > verifycn_name => undef, > SSL_verifycn_name => undef, > SSL_verifycn_scheme => undef, > SSL_verify_mode => undef > );

There is no verifycn_name option. Apart from that this just disables any verification your LDAP or CAS connections might want to do, so it might just be that there is a problem with certificate validation. A detailed description what kind of failures you get would be definitely helpful. Show quoted text

> This program is running fine on a RHEL6 distro using the following versions: > .... > IO::Socket::SSL v1.31 > .... > Migrating to RHEL7 caused this problem to exhibit. Our RHEL7 environment > has the following versions: > > IO::Socket::SSL v1.94

Please note that apart from IO::Socket::SSL and the Perl version there were probably also changes with other modules you use and which might affect the behavior. IO::Socket::SSL itself uses at least Net::SSLeay, but you use probably also Net::LDAP and other modules. Show quoted text

> ... > The error message we received when we migrated to RHEL7 was: > Not a GLOB reference at /usr/share/perl5/vendor_perl/IO/Socket/SSL.pm > line 1377

I don't see anything obviously wrong in this line. I would argue that it is simply called the wrong way (that is not with an IO::Socket::SSL object), but I would need to see the code which triggers the problem. It might just be that some (certificate verification) error occurred and that some code failed to catch the error properly, but this is just a wild guess. Show quoted text

> With the mitigation code in place we see the following issues in the web > server logs: > > Use of uninitialized value $verify_mode in numeric ne (!=) at > /usr/share/perl5/vendor_perl/IO/Socket/SSL.pm line 1649 > ... > Use of uninitialized value in subroutine entry at > /usr/share/perl5/vendor_perl/IO/Socket/SSL.pm line 1776

That is because you set SSL_verify_mode to undef, which is not a supported value (see documentation for the supported values). Show quoted text

> If this is not a bug/issue with IO::Socket::SSL I do apologize.

I don't know yet. If you would provide me a way to reproduce the problem I could have a look if this is a bug in IO::Socket::SSL and if this bug is fixed in the current version. Regards, Steffen

Thu Oct 30 13:19:42 2014 The RT System itself - Status changed from 'new' to 'open'

Thu Oct 30 13:44:27 2014 brian.biggs [...] sonoma.edu - Correspondence added

CC:	<behroozi [...] www.pls.uni.edu>
Subject:	Re: [rt.cpan.org #99910] possible bug/issue in IO::Socket::SSL v1.94
Date:	Thu, 30 Oct 2014 10:44:02 -0700
To:	<bug-IO-Socket-SSL [...] rt.cpan.org>
From:	Brian Biggs <brian.biggs [...] sonoma.edu>

Hi Steffan, Thank you for your reply. I completely understand that you will not put much effort into this. I will attempt to create some code which will exhibit this problem. I cannot provide you with the existing program as it includes code we would not want public. This may really be a Redhat issue since v1.94 is old and that is what they are distributing. I may try to get our sys admins to give me a RHEL7 system with the latest version of this library to see if the problem exists there. Thanks again, -Brian On 10/30/2014 10:19 AM, Steffen Ullrich via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=99910 > > > Hi Brian, > > the release of 1.94 was 06/2013. Since then 50 new versions were released. Please understand that I will not put too much effort into supporting such old versions. But of course I will look into the issue to see if it applies to current versions too. >

>> I've run into an issue where it seems that the use of certain global >> variables in IO::Socket::SSL have caused failures under certain >> circumstances. Specifically when a second SSL connection is made within >> the same program to a different host with a different SSL cert.

> Unfortunately this report does not contain enough information to reproduce the problem. Having multiple connections with different certificates at the same time is definitely supported, but there are issues when using threads. Please provide a test program or description, which is as simple as possible but clear enough to make the issue reproducible. >

>> I was able to mitigate the problem by clearing the globals like this: >> >> # Call this to mitigate a bug in IO::Socket::SSL which has some >> # global settings that don't get cleaned up between connections. >> # We also check for set_defaults() because the RHEL6 version of >> # IO::Socket::SSL doesn't have a set_defaults() function. >> defined(&IO::Socket::SSL::set_defaults) && >> IO::Socket::SSL::set_defaults( >> verifycn_name => undef, >> SSL_verifycn_name => undef, >> SSL_verifycn_scheme => undef, >> SSL_verify_mode => undef >> );

> There is no verifycn_name option. > Apart from that this just disables any verification your LDAP or CAS connections might want to do, so it might just be that there is a problem with certificate validation. A detailed description what kind of failures you get would be definitely helpful. >

>> This program is running fine on a RHEL6 distro using the following versions: >> .... >> IO::Socket::SSL v1.31 >> .... >> Migrating to RHEL7 caused this problem to exhibit. Our RHEL7 environment >> has the following versions: >> >> IO::Socket::SSL v1.94

> Please note that apart from IO::Socket::SSL and the Perl version there were probably also changes with other modules you use and which might affect the behavior. IO::Socket::SSL itself uses at least Net::SSLeay, but you use probably also Net::LDAP and other modules. >

>> ... >> The error message we received when we migrated to RHEL7 was: >> Not a GLOB reference at /usr/share/perl5/vendor_perl/IO/Socket/SSL.pm >> line 1377

> I don't see anything obviously wrong in this line. I would argue that it is simply called the wrong way (that is not with an IO::Socket::SSL object), but I would need to see the code which triggers the problem. It might just be that some (certificate verification) error occurred and that some code failed to catch the error properly, but this is just a wild guess. >

>> With the mitigation code in place we see the following issues in the web >> server logs: >> >> Use of uninitialized value $verify_mode in numeric ne (!=) at >> /usr/share/perl5/vendor_perl/IO/Socket/SSL.pm line 1649 >> ... >> Use of uninitialized value in subroutine entry at >> /usr/share/perl5/vendor_perl/IO/Socket/SSL.pm line 1776

> That is because you set SSL_verify_mode to undef, which is not a supported value (see documentation for the supported values). >

>> If this is not a bug/issue with IO::Socket::SSL I do apologize.

> I don't know yet. > If you would provide me a way to reproduce the problem I could have a look if this is a bug in IO::Socket::SSL and if this bug is fixed in the current version. > > Regards, > Steffen > >

-- Brian Biggs Sonoma State University

Wed May 13 16:55:58 2015 Steffen_Ullrich [...] genua.de - Correspondence added

Show quoted text

> ...I will attempt to create some code which will > exhibit this problem. I cannot provide you with the existing program > as it includes code we would not want public...

I will close this bug because of missing input. Maybe the problem was solved in the mean time.

Wed May 13 16:56:00 2015 Steffen_Ullrich [...] genua.de - Status changed from 'open' to 'rejected'

Thu May 14 11:25:00 2015 brian.biggs [...] sonoma.edu - Correspondence added

CC:	<behroozi [...] www.pls.uni.edu>
Subject:	Re: [rt.cpan.org #99910] possible bug/issue in IO::Socket::SSL v1.94
Date:	Thu, 14 May 2015 08:24:28 -0700
To:	<bug-IO-Socket-SSL [...] rt.cpan.org>
From:	Brian Biggs <brian.biggs [...] sonoma.edu>

Bug was never solved; however it was brought to the attention of Redhat who filed a bug for it for RHEL7. https://bugzilla.redhat.com/show_bug.cgi?id=1210032 -Brian On 05/13/2015 01:55 PM, Steffen Ullrich via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=99910 > >

>> ...I will attempt to create some code which will >> exhibit this problem. I cannot provide you with the existing program >> as it includes code we would not want public...

> I will close this bug because of missing input. Maybe the problem was solved in the mean time. >

-- Brian Biggs Sonoma State University

Fri May 15 02:52:15 2015 Steffen_Ullrich [...] genua.de - Correspondence added

On Thu May 14 11:25:00 2015, brian.biggs@sonoma.edu wrote: Show quoted text

> Bug was never solved; however it was brought to the attention of > Redhat > who filed a bug for it for RHEL7. > > https://bugzilla.redhat.com/show_bug.cgi?id=1210032

If I understand this right then this was not a bug in IO::Socket::SSL at all but in Net::LDAP, it was already fixed there two years ago and the only thing missing was the inclusion of the fix in RHEL7. Is this correct?

Fri May 15 09:57:57 2015 brian.biggs [...] sonoma.edu - Correspondence added

CC:	<behroozi [...] www.pls.uni.edu>
Subject:	Re: [rt.cpan.org #99910] possible bug/issue in IO::Socket::SSL v1.94
Date:	Fri, 15 May 2015 06:57:29 -0700
To:	<bug-IO-Socket-SSL [...] rt.cpan.org>
From:	Brian Biggs <brian.biggs [...] sonoma.edu>

I believe that is correct. My apologies for not following up with you. -Brian On 05/14/2015 11:52 PM, Steffen Ullrich via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=99910 > > > On Thu May 14 11:25:00 2015, brian.biggs@sonoma.edu wrote:

>> Bug was never solved; however it was brought to the attention of >> Redhat >> who filed a bug for it for RHEL7. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1210032

> If I understand this right then this was not a bug in IO::Socket::SSL at all but in Net::LDAP, it was already fixed there two years ago and the only thing missing was the inclusion of the fix in RHEL7. Is this correct? >

-- Brian Biggs Sonoma State University