Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69222
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAHMUw2HxcWgOBxiK=r4y6FgWF_Gkhgc6BgHxF_bgLLJG9RVxmQ@mail.gmail.com>
References: <CAH8MpnnTGD0xAwG1j9sh10EC6XzdscVRLbJzEMG6qWSBK5c17w@mail.gmail.com>
	<523A466C.4070903@gmail.com>
	<CAHMUw2HxcWgOBxiK=r4y6FgWF_Gkhgc6BgHxF_bgLLJG9RVxmQ@mail.gmail.com>
Date: Wed, 18 Sep 2013 22:51:02 -0400
Message-ID: <CAH8MpnkHQhyZtxzMJni3ADNFoZo26KuDvXgTtYRD9EVS1TfvTA@mail.gmail.com>
To: Tjerk Anne Meesters <datibbaw@php.net>
Cc: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= <keisial@gmail.com>, 
	johannes@schlueters.dot.de, addw@phcomp.dot.co.uk, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c39198ddfe6c04e6b39f01
Subject: Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
From: rdlowrey@gmail.com (Daniel Lowrey)

--001a11c39198ddfe6c04e6b39f01
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> While we're on the topic, it's actually worse than that. Even if you
> turn peer validation and name checking on, PHP can't handle
> subjectAltNames in certificates, which causes quite a few failures.

This is incorrect. PHP has supported both the "SNI_enabled" and
"SNI_server_name"
SSL context options since 5.3. Anything older than 5.3 is not remotely
worth worrying over. You can verify this for yourself using the following
code:

<?php
// reference: http://php.net/manual/en/context.ssl.php
$ctx =3D stream_context_create(['ssl' =3D> [
    'verify_peer' =3D> TRUE,
    'cafile' =3D> '/path/to/cacert.pem', // <-- change to point to an actua=
l
CA file
    'SNI_enabled' =3D> TRUE
]]);

$uri =3D https://sni.velox.ch/ // <--- A test site using SNI certs
$result =3D file_get_contents($uri, FALSE, $ctx);


P.S. Thank you to whomever updated
http://php.net/manual/en/context.ssl.phpto reflect the
"disable_compression" SSL stream context option (and
subsidized my laziness) :)



On Wed, Sep 18, 2013 at 9:06 PM, Tjerk Anne Meesters <datibbaw@php.net>wrot=
e:

>
>
>
> On Thu, Sep 19, 2013 at 8:33 AM, =C1ngel Gonz=E1lez <keisial@gmail.com> w=
rote:
>
>> 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 easie=
st
>>> 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 bundle
> to be shipped with PHP; perhaps this is a simple thing to do, I'm not sur=
e.
> 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.
>
>
>
>>
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> --
> --
> Tjerk
>

--001a11c39198ddfe6c04e6b39f01--