This is follow up to bug #746579. When you set HTTPS_CA_DIR or
HTTPS_CA_FILE in the environment, and use IO::Socket::SSL as the TLS
backend (which is the default), LWP does not verify that the hostname
matches the certificate's CN or subjectAltName:

$ HEAD https://5.153.231.4/ | head -n1
500 Can't connect to 5.153.231.4:443

$ HTTPS_CA_DIR=/etc/ssl/certs/ HEAD https://5.153.231.4/ | head -n1
200 OK


As I explained in the other bug, this is done for compatiblity with
Crypt::SSLeay, but:

* There's nothing in the names of HTTPS_CA_* that would suggests that
these variables are specific to Crypt::SSLeay, or LWP, or even Perl.
So people might have them set in their environment for purposes
unrelated to Crypt::SSLeay.

* I suspect that these days many users of LWP don't even know what
Crypt::SSLeay is.

* There is nothing in the LWP documentation that suggests that setting
HTTPS_CA_* might have negative security effect.

Hi,

as the maintainer of IO::Socket::SSL I strongly support this bug report.

First, like the author said, this behavior is unexpected and has serious
security implications.
Apart from that, disabling the verification of the hostname is more or less
the same as disabling any kind of certificate validation. If only the trust
chain is checked but not the hostname an attacker could simply get a valid
certificate for its own host and then use it to attack different hosts.

In my opinion the feature to disable validation of the hostname should not
only never enabled implicitely but should instead be removed. Of course
there can be cases where the hostname does not match, but in this case the
user can give the expected hostname with the `SSL_verifycn_name` option
or simply use certificate pinning with the `SSL_fingerprint` option, in
which case all other checks are disabled. Contrary to disabling the
hostname validation these kind of options are safe, because the user
explicitly defines what is expected.

Regards,
Steffen