Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63609
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
Sender: johnjawed@gmail.com
Date: Wed, 24 Oct 2012 22:03:48 -0700
Message-ID: <CAB75mSX-cMqZPTfv2vc8fakD_pr31qPR+kO5_O=zYiVoy4xH2w@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: Changing the default value of "true" for CURLOPT_SSL_VERIFYHOST
From: jawed@php.net (JJ)

Hey all - I'd like start a discussion around pull request 221
(https://github.com/php/php-src/pull/221).

In short, there's a high volume of [incorrect] code out there which looks like:

curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, true);

Instead of what, in all likelyhood, the code meant to do:

curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);

This is due to the convert_to_long_ex call which converts "true" to
1L. CURLOPT_SSL_VERIFYHOST being set to 1L bypasses common name
validation within libcurl.

My solution was to check the type for CURLOPT_SSL_VERIFYHOST: if it is
boolean and true, the opt value for libcurl is set to 2L.

I understand that engineers should have the proper option value to
begin with but weighing the impact of this (MITM attacks) against
doing what they probably meant anyways is worth the presumption.

Please discuss and adjust the patch if necessary.

- JJ