Skip Menu |
 

This queue is for tickets about the IO-Socket-SSL CPAN distribution.

Report information
The Basics
Id: 83289
Status: resolved
Priority: 0/
Queue: IO-Socket-SSL

People
Owner: Nobody in particular
Requestors: alex [...] gt.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: SSL connect attempt failed with unknown error
Date: Tue, 12 Feb 2013 13:28:47 -0800
To: bug-IO-Socket-SSL [...] rt.cpan.org
From: Alex Krohn <alex [...] gt.net>
Download (untitled) / with headers
text/plain 2.3k
Hi, This code with IO::Socket::SSL 1.83 and Net::SSLeay 1.52 fails: use lib 'IO-Socket-SSL-1.83/blib/lib'; use IO::Socket::SSL qw/debug2/; print "version: $IO::Socket::SSL::VERSION\n"; my $certclient = IO::Socket::SSL->new( PeerHost => "www.greencart.in:443") || die "failed"; with: version: 1.83 DEBUG: .../IO/Socket/SSL.pm:247: set domain to 2 ******************************************************************* Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client is deprecated! Please set SSL_verify_mode to SSL_VERIFY_PEER together with SSL_ca_file|SSL_ca_path for verification. If you really don't want to verify the certificate and keep the connection open to Man-In-The-Middle attacks please set SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application. ******************************************************************* at test line 7 DEBUG: .../IO/Socket/SSL.pm:420: socket not yet connected DEBUG: .../IO/Socket/SSL.pm:422: socket connected DEBUG: .../IO/Socket/SSL.pm:440: ssl handshake not started DEBUG: .../IO/Socket/SSL.pm:1395: SSL connect attempt failed with unknown error DEBUG: .../IO/Socket/SSL.pm:510: fatal SSL error: SSL connect attempt failed with unknown error error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112) failed at test line 7. If I use IO::Socket::SSL 1.35 (what was previously installed), works fine: version: 1.35 DEBUG: .../IO/Socket/SSL.pm:191: set domain to 2 DEBUG: .../IO/Socket/SSL.pm:332: socket not yet connected DEBUG: .../IO/Socket/SSL.pm:334: socket connected DEBUG: .../IO/Socket/SSL.pm:347: ssl handshake not started DEBUG: .../IO/Socket/SSL.pm:445: ssl handshake done Most domains work, it's just this one in particular that causes a problem. I suspect what is weird about this domain is www.greencart.in common name is 'greencart.in', but does supply alternative subject names of 'www.greencart.in'. So I think something needs updating to work with alternative subject names, but I'm not finding it. I suspect this might actually be a bug in Net::SSLeay, but having trouble getting a small test case to reproduce (as I think what is different between IO::Socket::SSL is the initialization to Net::SSLeay). Thanks for any help you can offer! Cheers, Alex
Subject: Re: [rt.cpan.org #83289] AutoReply: SSL connect attempt failed with unknown error
Date: Tue, 12 Feb 2013 18:04:35 -0800
To: bug-IO-Socket-SSL [...] rt.cpan.org
From: Alex Krohn <alex [...] gt.net>
Download (untitled) / with headers
text/plain 310b
Hi, Ok, more investigation this seems to be an openssl issue described here: http://www.mail-archive.com/openssl-users@openssl.org/msg65511.html Adding: SSL_version => 'TLSv1' or SSL_version => 'SSLv3' lets things connect ok. I suppose this makes it an openssl bug. Sorry for the noise! Cheers, Alex
Download (untitled) / with headers
text/plain 517b
On Tue Feb 12 21:05:13 2013, alex.krohn wrote: Show quoted text
> Hi, > > Ok, more investigation this seems to be an openssl issue described here: > > http://www.mail-archive.com/openssl-users@openssl.org/msg65511.html > ... > > lets things connect ok. I suppose this makes it an openssl bug.
I guess it is depending on the openssl version you use. Cannot reproduce it with a recent openssl. If the problem is, that the server cannot deal with the Server Name Identification, you could switch it off by setting SSL_hostname => ''
Subject: Re: [rt.cpan.org #83289] SSL connect attempt failed with unknown error
Date: Tue, 12 Feb 2013 21:57:06 -0800
To: bug-IO-Socket-SSL [...] rt.cpan.org
From: Alex Krohn <alex [...] gt.net>
Download (untitled) / with headers
text/plain 628b
Show quoted text
> I guess it is depending on the openssl version you use. > Cannot reproduce it with a recent openssl. > If the problem is, that the server cannot deal with the Server Name Identification, you could switch it off > by setting SSL_hostname => ''
Can reproduce it on several boxes, all on 0.9.8 openssl. Weird that changing the IO::Socket::SSL version masks the error with the same openssl. Passing SSL_hostname => '' also "fixes" the problem (as does passing SSL_version => 'TLSv1' or SSL_version => 'SSLv3'). Now I wonder what a good fix is to handle this generically (i.e. still want ssl verification on and enabled). =)
Subject: Re: [rt.cpan.org #83289] SSL connect attempt failed with unknown error
Date: Wed, 13 Feb 2013 07:55:34 +0100
To: Alex Krohn via RT <bug-IO-Socket-SSL [...] rt.cpan.org>
From: Steffen Ullrich <Steffen_Ullrich [...] genua.de>
Download (untitled) / with headers
text/plain 599b
Show quoted text
> Can reproduce it on several boxes, all on 0.9.8 openssl. Weird that > changing the IO::Socket::SSL version masks the error with the same > openssl.
That's because support for Server Name Identification was introduced in 1.56. Show quoted text
> > Passing SSL_hostname => '' also "fixes" the problem (as does passing > SSL_version => 'TLSv1' or SSL_version => 'SSLv3'). > > Now I wonder what a good fix is to handle this generically (i.e. still > want ssl verification on and enabled). =)
I think I'll need to check the openssl version before using SNI. Seems like newer version fixed the problem. Steffen
Download (untitled) / with headers
text/plain 438b
Show quoted text
> > Now I wonder what a good fix is to handle this generically (i.e.
> still
> > want ssl verification on and enabled). =)
> > I think I'll need to check the openssl version before using SNI. > Seems like newer version fixed the problem.
I checked several openssl versions and there is no 0.9.8* version, which is not affected by this bug, but 1.0.0 is fine. So starting with 1.84 client side SNI is only enabled for OpenSSL >= 1.0.0.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.