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)



MIME-Version: 1.0
X-Spam-Status: No, score=-1.999 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001] autolearn=ham
X-Spam-Flag: NO
content-type: text/plain; charset="utf-8"
Message-ID: <536527D7.7070506 [...] ukr.net>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Spam-Score: -1.999
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id C5F8024075A for <cpan-bug+IO-Socket-SSL [...] hipster.bestpractical.com>; Sat, 3 May 2014 13:31:13 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJPEpxXFuW38 for <cpan-bug+IO-Socket-SSL [...] hipster.bestpractical.com>; Sat, 3 May 2014 13:31:12 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 41B0E240742 for <bug-IO-Socket-SSL [...] rt.cpan.org>; Sat, 3 May 2014 13:31:11 -0400 (EDT)
Received: (qmail 24910 invoked by alias); 3 May 2014 17:31:11 -0000
Received: from frv152.fwdcdn.com (HELO frv152.fwdcdn.com) (212.42.77.152) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Sat, 03 May 2014 10:31:08 -0700
Received: from [95.158.11.2] (helo=[192.168.1.4]) by frv152.fwdcdn.com with esmtpsa ID 1WgdmB-000Cvs-K1 for bug-IO-Socket-SSL [...] rt.cpan.org; Sat, 03 May 2014 20:31:03 +0300
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] ukr.net
Delivered-To: cpan-bug+IO-Socket-SSL [...] hipster.bestpractical.com
Subject: Valid certificate, verification failed
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0
Return-Path: <purification [...] ukr.net>
X-RT-Mail-Extension: io-socket-ssl
X-Original-To: cpan-bug+IO-Socket-SSL [...] hipster.bestpractical.com
X-Spam-Check-BY: la.mx.develooper.com
Dkim-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Jv0muD63Kp880CMmaqY98sGjIthrnvbsIzWnr8OWghk=; b=DVnusmshfpXsC5WwJhFWt+My09zOXHULad/AiKnrU43WuJv/pFhRRq+8cDosvA7G12PShI1jN/gI5R/fKDFYhjrbuCCh+8ZjRjkpOF4Dm12N11ic0P7rAywEg0vFxBRaS93WnNf85IKuBXxXh6TKbM8/YdFoepFXayafC3xAjCE=;
Authentication-Result: IP=95.158.11.2; mail.from=purification [...] ukr.net; dkim=pass; header.d=ukr.net
Date: Sat, 03 May 2014 20:31:03 +0300
X-Spam-Level:
To: bug-IO-Socket-SSL [...] rt.cpan.org
Content-Transfer-Encoding: 7bit
X-Enigmail-Version: 1.6
From: fake <purification [...] ukr.net>
X-RT-Original-Encoding: iso-8859-1
X-RT-Interface: Email
Content-Length: 2362
Download (untitled) / with headers
text/plain 2.3k
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 );
MIME-Version: 1.0
In-Reply-To: <536527D7.7070506 [...] ukr.net>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <536527D7.7070506 [...] ukr.net>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-12102-1399156691-1187.95317-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 650
Download (untitled) / with headers
text/plain 650b
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.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-12102-1399156691-1187.95317-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <536527D7.7070506 [...] ukr.net> <rt-4.0.18-12102-1399156691-1187.95317-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-20319-1399190580-1173.95317-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 129
Download (untitled) / with headers
text/plain 129b
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.


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.