Skip Menu |

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

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

People
Owner: Nobody in particular
Requestors: purification [...] ukr.net
Cc:
AdminCc:

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



Subject: Valid certificate, verification failed
Date: Sat, 03 May 2014 20:31:03 +0300
To: bug-IO-Socket-SSL [...] rt.cpan.org
From: fake <purification [...] ukr.net>
I am using LWP::UserAgent to fetch https links. With newer version of IO::Socket::SSL complains about valid certificates which breaks my script. The problem is: #!/usr/bin/env perl # Saturday 2014-05-03 18:06:16 # testing a problem with IO::Socket::SSL 1.982 use strict; use warnings; use IO::Socket::SSL qw[debug3]; my $client = IO::Socket::SSL->new( PeerHost => 'ajax.googleapis.com', # PeerHost => 'gdata.youtube.com', PeerPort => 443, IO::Socket::SSL::default_ca(), # gives us default SSL_ca_path, in my case /usr/lib/ssl/certs ) or die "**CONSTRUCTOR FAILURE** \n\n $! \n\n $SSL_ERROR"; print "Constructor worked\n"; Which gives a warning like: The verification of cert '/C=US/O=Google Inc/CN=Google Internet Authority G2/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.googleapis.com' failed against the host 'ajax.googleapis.com' with the default verification scheme. THIS MIGHT BE A MAN-IN-THE-MIDDLE ATTACK !!!! To stop this warning you might need to set SSL_verifycn_name to the name of the host you expect in the certificate. Which is obviously wrong, because ajax.googleapis.com has a valid certificate. After some debugging I was able to track this problem down to the fact that IO::Socket::SSL::PublicSuffix has googleapis.com in list of domains. Test case looks like: #!/usr/bin/env perl # Saturday 2014-05-03 18:06:16 # testing a problem with IO::Socket::SSL 1.982 # - tracking it down to IO::Socket::SSL::PublicSuffix use strict; use warnings; use Data::Dumper; use IO::Socket::SSL::PublicSuffix; my $ps = IO::Socket::SSL::PublicSuffix->default; # TEST 1: google apis host and certificate my $name = '*.googleapis.com'; my $identity = 'ajax.googleapis.com'; # lines from IO-Socket-SSL.pm my @labels = split( m{\.+}, $identity ); my $tld = $ps->public_suffix(\@labels,+1); print("DEBUG: labels and tld for $name\n".Dumper(\@labels).Dumper($tld)); # TEST 2: youtube api host & certificate $name = '*.youtube.com'; $identity = 'gdata.youtube.com'; @labels = split( m{\.+}, $identity ); $tld = $ps->public_suffix(\@labels,+1); print("DEBUG: labels and tld for $name\n".Dumper(\@labels).Dumper($tld)); And because of the fact that $ps->public_suffix returns a strange result for ajax.googleapis.com, the validation fails at line 1403 of SSL.pm Show quoted text
> return 1 if @labels > ( $tld ? 0+@$tld : 1 );
Show quoted text
> PeerHost => 'ajax.googleapis.com',
Thank you for you bug report. You already correctly identified the problem as coming from the public suffix checking. It looks like that google ones claimed, that googleapis.com should be handled like a top-level domain, e.g. no ajax.googleapis.com should be allowed, but only www.ajax.googleapis.com. Unfortunatly this does not seem true anymore, so one has to work around the old setting. I'll add an exception into the default list which comes from Mozilla. In the mean time you can work around it by adding SSL_verifycn_publicsuffix => '' to the SSL options, which disables the checks against the list.
It is fixed in 1.983 - and it was a fault in IO::Socket::SSL use of the public suffix list, not in the public suffix list itself.