LWP :: UserAgent Insists on hostname validation

Question

The following script operations return full headers on a host running libwww-perl-5.836 but not on a host using libwww-perl-6.30.0 . In this case, the script displays the following:

  500 Can't connect to backend.mutegroup.org:443 (certificate verify failed) Content-Type: text/plain Client-Date: Mon, 28 Jul 2014 21:09:28 GMT Client-Warning: Internal response Can't connect to backend.mutegroup.org:443 (certificate verify failed) LWP::Protocol::https::Socket: SSL connect attempt failed with unknown error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/lib64/perl5/vendor_perl/5.16.3/LWP/Protocol/http.pm line 51. 

This is the script:

 #!/usr/bin/perl use strict; use warnings; use LWP::UserAgent; use HTTP::Request::Common; my $ua = LWP::UserAgent->new(ssl_opts => { verify_hostname => 0, } ); my $url = 'https://backend.mutegroup.org/api/getLastId'; my $request = POST $url; print $ua->request($request)->as_string 

Host names are not checked by default for libwww-perl-5.837 and earlier. This explains why it is running on the old host. However, I explicitly turned off the checks, and he still insists on doing them.

This is a Gentoo system.

Answer 1

You have disabled host name verification; You have not disabled certificate verification.

verify_hostname determines whether "LWP for secure protocol schemes" will connect to servers that have a valid certificate that matches the expected host name "(my emphasis). Setting this parameter to 0 allows you to connect to a server that has a valid certificate but is not specified for the host / hostname you are trying to reach.

To disable certificate authentication (issued by a trusted CA), you want to:

 use IO::Socket::SSL; my $ua = LWP::UserAgent->new( ssl_opts => { verify_hostname => 0, SSL_verify_mode => IO::Socket::SSL::SSL_VERIFY_NONE, }, ); 

Note that disabling any of these options is a bad idea if you are transmitting any sensitive information or are hoping to trust the returned data. With any of these outages, you lose the benefits of SSL and are vulnerable to various man-in-the-middle attacks.