Show quoted text> 3) Therefore, users of Crypt::SSLeay end up opting in to use
> IO::Socket::SSL unless THEY TAKE SPECIFIC ACTION to force LWP to use
> Crypt::SSLeay, and use it without hostname verification.
You are correct, but unfortunately you find the recommendation to do exactly this on lots of places.
If you search for "lwp ssl" or "lwp https" you find Crypt::SSLeay and examples which enforce use of it in the top search hits and if you monitor stackoverflow you see people referring with https problems in LWP to old posts describing the use of Crypt::SSLeay or even actively recommend to enforce use of Crypt::SSLeay over IO::Socket::SSL. And because this often solves the problem, users will do it. I try to find and refute this posts and give the correct recommendations, but it's a hard fight because often it needs the help from the user to pin down the real problem instead of just ignoring it.
And, of course, usually none of the posters which recommend Crypt::SSLeay point out where you decrease the security if you use it instead of IO::Socket::SSL, because the poster usually does not understand the problem either.
And while I appreciate that Crypt::SSLeay explicitly recommends to not use it and to use IO::Socket::SSL instead, probably most users install Crypt::SSLeay not from the source. From
http://www.activestate.com/activeperl/ppm-perl-modules I see that Crypt::SSLeay is packaged with ActiveState Perl while IO::Socket::SSL is not, which means that LWP (with the help of Net::HTTPS) will probably silently fall back to use Crypt::SSLeay unless the user specifically installs IO::Socket::SSL. And while Debian has the dependencies correctly you can also install Crypt::SSLeay there easily without getting any warnings that it should better not be used.
Show quoted text> Then, you will get:
>
> > Can't connect to www.example.com:443 (Crypt-SSLeay can't verify
> > hostnames)
>
> > Net::SSL from Crypt-SSLeay can't verify hostnames;
> > either install IO::Socket::SSL or turn off verification
> > by setting the PERL_LWP_SSL_VERIFY_HOSTNAME environment
> > variable to 0
>
> That is, it is not possible to silently disable host verification by
> installing Crypt::SSLeay. One must TAKE SPECIFIC ACTION to do that.
>
> While that may not be desirable from your perspective, I do not see
> the concern if people knowingly do something.
If the user has environment settings for HTTPS_CA_FILE or HTTPS_CA_DIR it will not need to set PERL_LWP_SSL_VERIFY_HOSTNAME because LWP::UserAgent assumes that the user upgraded from Crypt::SSLeay and will *silently* disable hostname verification (see source of LWP::UserAgent::new). Of course you find the recommendations to set HTTPS_CA_* this way because older LWP versions did not depend on Mozilla::CA and thus needed a way to specify the place for the trusted CA. You also find these environment variables documented in LWP::UserAgent without the information that it will disable hostname verification if you use them.
Also, lots of users don't understand why the hostname verification is an important part of SSL and that just checking for a proper CA is not sufficient. So they just follow the recommendation to disable it. IO::Socket::SSL provides a better way to deal with this problem: If the hostname in the certificate is not the name inside the URL you can knowingly provide another hostname it should use instead to verify the certificate. Thus you keep the check against the expected hostname and this is much more secure than completely disabling hostname verification.
Show quoted text> What is the action item with which you are offering to help? Right
> now, things are set up such that people who choose not to verify
> hostnames can, but people who take no specific action opt in to using
> hostname verification. As in the following program:
One goal I have is that LWP should do the right thing out of the box and that it should be very hard to unknowingly do the bad thing. Right now it is just too easy to do the wrong thing accidentally. Removing support for Crypt::SSLeay would help here, but one has to be sure that there are no important use cases anymore (like platforms unsupported by IO::Socket::SSL but supported by Crypt::SSLeay).
I'm not sure if Crypt::SSLeay has other users than LWP. If this is the case one could enhance Crypt::SSLeay by making it a wrapper around IO::Socket::SSL and that is where I offered help. But, if LWP is the only important user then this would not be necessary.
Regards,
Steffen
