Arnaud Ebalard wrote:
> Hi,
>
> Jef Gearhart <jef_at_tpssys.com> writes:
>
>
>> Maybe this was intentional? If I try to use CURLOPT_SSL_VERIFYHOST
>> (set to 2), but disable CURLOPT_SSL_VERIFYPEER, the connection
>> succeeds, even though the Common name doesn't match the host name I
>> connected to.
>>
>> I can see clearly in the code why this is so, but before I elaborate
>> on that.. Is this intentional?
>>
>
> I think it is not (even if setting the former while unsetting the latter
> seems pointless from a security standpoint).
>
> During tests involving libcurl-gnutls, I had the expected behavior
> (IIRC). Are you using the libssl-based version?
>
> Cheers,
>
> a+
>
Yes, if that means the OpenSSL flavor, then yes.

The problem is identified to be around line1733 in ssluse.c (libcurl v
7.18.2)..

Here's one way to fix it, but I would defer to the masters for any
official fix..

1733 (ssluse.c) ---------------------------

  if(!data->set.ssl.verifypeer)
#ifdef GEARHART_DOESNT_WORK_HERE
     (void)servercert(conn, connssl, FALSE);
#else
  {
     if (!data->set.ssl.verifyhost)
       (void)servercert(conn, connssl, FALSE);
     else
        retcode = servercert(conn, connssl, FALSE);

     if (retcode == CURLE_PEER_FAILED_VERIFICATION)
        failf(data, "SSL Host verification failed");
     else
        retcode = CURLE_OK;
  }
#endif
  else
    retcode = servercert(conn, connssl, TRUE);

-----------------------

Thanks to all who replied.
Received on 2008-07-09