Skip Menu |
 

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

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

People
Owner: Nobody in particular
Requestors: carnil [...] debian.org
Cc:
AdminCc:

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



CC: 606243 [...] bugs.debian.org, 606243-submitter [...] bugs.debian.org
Subject: IO::Socket::SSL fails when verify_callback is supplied without ca_path or ca_file
Date: Wed, 8 Dec 2010 16:05:57 +0100
To: bug-IO-Socket-SSL [...] rt.cpan.org
From: Salvatore Bonaccorso <carnil [...] debian.org>
Hi! Daniel Kahn Gillmor reported the message below to the Debian bugtracker [1]. If one explicitly supply a verify_callback but do not pass ca_file and ca_path locations or the default are not populated, then IO::Socket::SSL will trow error 'Invalid certificate authority locations'. Would it make sense, to allow, if a user is suppliying an own verify_callback to IO::Socket::SSL then to not fail? [1] http://bugs.debian.org/606243 Thanks for your comments. Bests Salvatore ----- Forwarded message from Daniel Kahn Gillmor <dkg@fifthhorseman.net> ----- From: Daniel Kahn Gillmor <dkg@fifthhorseman.net> Resent-From: Daniel Kahn Gillmor <dkg@fifthhorseman.net> Reply-To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 606243@bugs.debian.org X-Mailer: reportbug 4.12.6 Date: Tue, 07 Dec 2010 13:41:21 -0500 To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: Bug#606243: libio-socket-ssl-perl: IO::Socket::SSL fails when verify_callback is supplied without ca_path or ca_file Package: libio-socket-ssl-perl Version: 1.35-1 Severity: normal Tags: patch if i supply a verify_callback to IO::Socket::SSL, but fail to supply ca_file or ca_path (and the default ca_file and ca_path locations are not populated), initialization fails. This is silly because i'm using my own verify_callback, and so i don't need to give OpenSSL a ca_file or ca_path. The attached patch fixes it for me. --dkg -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.36-trunk-686 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libio-socket-ssl-perl depends on: ii libnet-ssleay-perl 1.36-1 Perl module for Secure Sockets Lay ii netbase 4.43 Basic TCP/IP networking system ii perl 5.10.1-16 Larry Wall's Practical Extraction Versions of packages libio-socket-ssl-perl recommends: ii libnet-libidn-perl 0.12.ds-1+b1 Perl bindings for GNU Libidn Versions of packages libio-socket-ssl-perl suggests: pn libio-socket-inet6-perl <none> (no description available) -- no debconf information diff --git a/SSL.pm b/SSL.pm index ee2d85e..0cd640b 100644 --- a/SSL.pm +++ b/SSL.pm @@ -1366,7 +1366,8 @@ sub new { if ( $verify_mode != Net::SSLeay::VERIFY_NONE() and ! Net::SSLeay::CTX_load_verify_locations( $ctx, $arg_hash->{SSL_ca_file} || '',$arg_hash->{SSL_ca_path} || '') ) { - return IO::Socket::SSL->error("Invalid certificate authority locations"); + return IO::Socket::SSL->error("Invalid certificate authority locations") + if (! defined $arg_hash->{SSL_verify_callback}); } if ($arg_hash->{'SSL_check_crl'}) { Show quoted text
_______________________________________________ pkg-perl-maintainers mailing list pkg-perl-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers
----- End forwarded message -----

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

Download signature.asc
application/pgp-signature 835b

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 600b
it's not that simple: - usually SSL_verify_callback is used together with a valid CA file or CA path, because one wants to let openssl pre-check the certificate and only add additional checks (see SSL_set_verify openssl docs), - if SSL_verifycn_scheme is set there will be an implicite SSL_verify_callback which checks the name in the certificate Because the case, that somebody wants to check the certificate completly by itself w/o having openssl check the certificate chain, is IMHO uncommon, I don't change the code for now. I think it is safer than risk to not doing certificate checks.
CC: 606243 [...] bugs.debian.org, bug-IO-Socket-SSL [...] rt.cpan.org, behroozi [...] www.pls.uni.edu
Subject: [rt.cpan.org #63741] Re: Bug#606243: IO::Socket::SSL fails when verify_callback is supplied without ca_path or ca_file
Date: Wed, 08 Dec 2010 17:07:17 -0500
To: Salvatore Bonaccorso <carnil [...] debian.org>
From: Daniel Kahn Gillmor <dkg [...] fifthhorseman.net>
Download (untitled) / with headers
text/plain 1.4k
On 12/08/2010 04:24 PM, Salvatore Bonaccorso wrote: Show quoted text
> ----- Forwarded message from Steffen Ullrich via RT <bug-IO-Socket-SSL@rt.cpan.org> ----- > it's not that simple: > - usually SSL_verify_callback is used together with a valid CA file or > CA path, because one wants to let openssl pre-check the certificate > and only add additional checks (see SSL_set_verify openssl docs), > - if SSL_verifycn_scheme is set there will be an implicite > SSL_verify_callback which checks the name in the certificate > > Because the case, that somebody wants to check the certificate completly > by itself w/o having openssl check the certificate chain, is IMHO > uncommon, I don't change the code for now.
Hrm. i'm doing it with a tool i hope to release later this week, actually [0], so while it might be uncommon, it does happen. What do you suggest i do to make this work? maybe i should do something like: ca_path => '/' ? That seems pretty weird to me. Can you recommend a better way that i can fully disable these checks, or is this the best way? Show quoted text
> I think it is safer than risk to not doing certificate checks.
What do you think is the risk here? If no trusted root authorities are supplied (by either ca_path or ca_file), but a verify callback is present, that verify callback will simply never see a preverify_ok argument set to 1, right? why is that dangerous? --dkg [0] https://labs.riseup.net/code/issues/2016
Download signature.asc
application/pgp-signature 900b

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 828b
Show quoted text
> What do you think is the risk here? If no trusted root authorities > are > supplied (by either ca_path or ca_file), but a verify callback is > present, that verify callback will simply never see a preverify_ok > argument set to 1, right? why is that dangerous?
The risk is, that usually one wants to have the certificate checks and only add additional checks (like for valid hostname) on top. So if it silently ignores unusable SSL_ca_* the validation can succeed even if the certs are not signed by a trusted authority. I've no released version 1.37. Here you can explicitly set SSL_ca_path and SSL_ca_file to undef, so that it does not try to use them (if you leave them unset the default will be used, so you need to set them explicitly to undef). I did not test it, so please let me know if it works for you. Steffen
CC: 606243 [...] bugs.debian.org, bug-IO-Socket-SSL [...] rt.cpan.org
Subject: Re: Bug#606243: [rt.cpan.org #63741] Re: Bug#606243: IO::Socket::SSL fails when verify_callback is supplied without ca_path or ca_file
Date: Mon, 13 Dec 2010 14:14:21 -0500
To: Salvatore Bonaccorso <carnil [...] debian.org>
From: Daniel Kahn Gillmor <dkg [...] fifthhorseman.net>
Download (untitled) / with headers
text/plain 387b
On 12/09/2010 10:26 AM, Salvatore Bonaccorso wrote: Show quoted text
> I just uploaded 1.37 to unstable. See [1] for Steffen's answer. > > [1] https://rt.cpan.org/Public/Bug/Display.html?id=63741#txn-866329 > > Could you please test it?
Yes, IO::Socket::SSL 1.37 appears to work for my purposes with ca_file and ca_path set to undef. Thanks to everyone involved for their quick responses! --dkg
Download signature.asc
application/pgp-signature 900b

Message body not shown because it is not plain text.

problem solved


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.