Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69238
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADajX4BudWBoKwZ8Xo5_QENQifdH2V3MDXe3vGszWkPAbwgjZw@mail.gmail.com>
References: <CAH8MpnnTGD0xAwG1j9sh10EC6XzdscVRLbJzEMG6qWSBK5c17w@mail.gmail.com>
	<523A466C.4070903@gmail.com>
	<CAHMUw2HxcWgOBxiK=r4y6FgWF_Gkhgc6BgHxF_bgLLJG9RVxmQ@mail.gmail.com>
	<CAEZPtU7YjNksHLEyH9VzM-iDdpQmBeJkF-BHPkAajZjiQS5XBA@mail.gmail.com>
	<CAHMUw2Gv=JdswmWVHCvp2S3WECVPEx4aWOQzF2yLMHaqJ5HK-g@mail.gmail.com>
	<000001ceb53c$492a3090$db7e91b0$@org>
	<CAH8MpnkX1p66AxeDXYaDiNaPBL635gKLXmS6qN=veB4H4CTicw@mail.gmail.com>
	<CADajX4BudWBoKwZ8Xo5_QENQifdH2V3MDXe3vGszWkPAbwgjZw@mail.gmail.com>
Date: Thu, 19 Sep 2013 17:31:11 -0700
Message-ID: <CAEZPtU6moG46an2nAGUjqyvjbQo+pwRSGAv4PPy8NKAtbKU30g@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: Daniel Lowrey <rdlowrey@gmail.com>, "Bryan C. Geraghty" <bryan@ravensight.org>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey <aharvey@php.net> wrote:
> On 19 September 2013 10:52, Daniel Lowrey <rdlowrey@gmail.com> wrote:
>>> *I consider this a bug* I understand that it's easier to code not verif=
ying the
>>> peer, and the hostname may not be available when you are stacking ssl o=
ver a stream.
>>> But file_get_contents("https://...") is *precisely* the case that shoul=
d work right
>>> out of the box.
>>
>> ^^ This.
>>
>> Before I can fully/cleanly implement these changes we need to decide
>> if PHP wants to move to a secure-by-default model for streams
>> utilizing the built in encryption wrappers. Thoughts?
>
> I think we should do this in 5.6. cURL has behaved this way for
> literally years at this point (verify by default, provide a switch to
> disable verification) and users seem to do just fine there. The much
> improved security story outweighs the (admittedly present) BC issues
> for mine.
>
> As for the CA bundle side of things, I wonder if this is one of those
> rare times where an ini setting might make sense, as opposed to actual
> bundling =97 that would allow distros to point to their packaged bundles
> without needing to patch php-src, and we could provide from-source
> installation instructions easily enough to point to common distro
> locations and the cURL download for users on more exotic OSes (like
> Windows).

Windows supports that very well, with Curl for example. It can also
uses the OS certificates database.

For the record here, curl has this setting already:

http://us2.php.net/manual/en/curl.configuration.php#ini.curl.cainfo

which is around for quite some time already.

It could be possible to share it with openssl, but back then I did not
check it out as only curl was concerned.

One thing I do not remember off hand is if we actually enable cert
validation per default with php's curl. It should be as we discussed
that already many times.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org