Review how CURLOPT_SSL_VERIFYHOST option is treated in eppclient

Reported in email from Ondrej Sury:

Hi,

eppclient from the opendnssec sources is not built and distributed as
a part of Debian binary packages.

However I am relaying your message to the upstream.

Ondrej.

On Sun, Nov 25, 2012 at 4:20 PM, Alessandro Ghedini <ghedo@debian.org> wrote:
Hi,

I recently discovered that opendnssec is using the libcurl API in a way that may
not be what the original author intended. In particular I'm referring to the
fact that the CURLOPT_SSL_VERIFYHOST option is treated as it was a boolean value
while in fact it isn't (it may take three different values):

curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1L);
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 1L);

(from the file plugins/eppclient/src/epp.c)

Setting the value to "1" does not enable the host checks (well, not all of them)
and this may lead to security issues. The correct value to enable all the
security checks is "2".

From the libcurl documentation:

When CURLOPT_SSL_VERIFYHOST is 2, that certificate must indicate that the
server is the server to which you meant to connect, or the connection fails.

Curl considers the server the intended one when the Common Name field or a
Subject Alternate Name field in the certificate matches the host name in the
URL to which you told Curl to connect.

When the value is 1, the certificate must contain a Common Name field, but it
doesn't matter what name it says. (This is not ordinarily a useful setting).

When the value is 0, the connection succeeds regardless of the names in the
certificate.

After discussing this with the security team, it was decided that it would be
best if this was fixed before the Wheezy release.

Note that this should be fixed anyway, since as of curl v7.28.1 (which will soon
be uploaded to experimental) the value "1" is not a valid value anymore and
libcurl will return an error.

A possible fix should be discussed with the opendnssec upstream first.

Cheers