Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69227
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.41 as permitted sender)
MIME-Version: 1.0
Sender: tjerk.meesters@gmail.com
In-Reply-To: <CAEZPtU7YjNksHLEyH9VzM-iDdpQmBeJkF-BHPkAajZjiQS5XBA@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>
Date: Thu, 19 Sep 2013 17:01:01 +0800
Message-ID: <CAHMUw2Gv=JdswmWVHCvp2S3WECVPEx4aWOQzF2yLMHaqJ5HK-g@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: johannes@schlueters.dot.de, addw@phcomp.dot.co.uk, 
	Daniel Lowrey <rdlowrey@gmail.com>, "internals@lists.php.net" <internals@lists.php.net>, 
	=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= <keisial@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b33d3740dc2d404e6b8cb89
Subject: Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
From: datibbaw@php.net (Tjerk Anne Meesters)

--047d7b33d3740dc2d404e6b8cb89
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 19, 2013 at 2:02 PM, Pierre Joye <pierre.php@gmail.com> wrote:

>
> On Sep 18, 2013 6:07 PM, "Tjerk Anne Meesters" <datibbaw@php.net> wrote:
> >
> > On Thu, Sep 19, 2013 at 8:33 AM, =C1ngel Gonz=E1lez <keisial@gmail.com>
> wrote:
> >
> > > On 16/09/13 15:58, Daniel Lowrey wrote:
> > >
> > >> More generally, PHP's stream encryption aspects are quite poorly
> > >> documented. For example, https:// streams disable peer verification
> by
> > >> default. While I understand that this is necessary to provide the
> easiest
> > >> possible user experience for things like `file_get_contents("
> > >> https://somesite.com")`, it's also horribly insecure. 99% of people
> using
> > >> tools like this won't know anything about this "feature" and won't
> realize
> > >> that their stream transfers are totally vulnerable to
> Man-in-the-Middle
> > >> attacks by default.
> > >>
> > > Count me as one of those that didn't know https:// streams didn't
> verify
> > > certificates. :)
> > > *I consider this a bug* I understand that it's easier to code not
> > > verifying the
> > > peer, and the hostname may not be available when you are stacking ssl
> over
> > > a stream.
> > > But file_get_contents("https://...**") is *precisely* the case that
> > > should work right
> > > out of the box.
> >
> >
> > To be practical, verifying certificates requires an up-to-date CA bundl=
e
> to
> > be shipped with PHP; perhaps this is a simple thing to do, I'm not sure=
.
> > This is an oft seen scenario for cURL; the developer would see the
> > certificate issue, search online and continue with `CURLOPT_VERIFY_PEER
> =3D>
> > 0`. That said, at least cURL is configured to check the certificate by
> > default.
> >
>
> FYI, curl allows to give the path to a cert db, it can be set in php.ini
> too (if I remember correctly)
>
Yes, I know that. This can also be done with the ca_file / ca_path context
options when you use streams. My point is that you need a reasonably
up-to-date certs bundle to enable verification by default.

It could be impractical to ship such a bundle with php itself, in which
case one might consider updating the documentation to highlight where such
cert bundles can be downloaded from.


--=20
--
Tjerk

--047d7b33d3740dc2d404e6b8cb89--