Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69234
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <000001ceb53c$492a3090$db7e91b0$@org>
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>
Date: Thu, 19 Sep 2013 13:52:27 -0400
Message-ID: <CAH8MpnkX1p66AxeDXYaDiNaPBL635gKLXmS6qN=veB4H4CTicw@mail.gmail.com>
To: "Bryan C. Geraghty" <bryan@ravensight.org>
Cc: Tjerk Anne Meesters <datibbaw@php.net>, Pierre Joye <pierre.php@gmail.com>, johannes@schlueters.dot.de, 
	addw@phcomp.dot.co.uk, "internals@lists.php.net" <internals@lists.php.net>, 
	=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= <keisial@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit
From: rdlowrey@gmail.com (Daniel Lowrey)

> If a subjectAltName extension of type dNSName is present, that MUST
> be used as the identity. Otherwise, the (most specific) Common Name
> field in the Subject field of the certificate MUST be used. Although
> the use of the Common Name is existing practice, it is deprecated and
> Certification Authorities are encouraged to use the dNSName instead.

I have a working patch locally that adds SAN verification pursuant to
RFC 2818 as outlined here (mentioned by Ryan):

http://tools.ietf.org/html/rfc2818#section-3.1

Usage looks like this:

```
$ctx = stream_context_create(['ssl' => [
    'verify_peer' => TRUE,
    'cafile' => '/path/to/cacert.pem',
    'SAN_required' => TRUE, // default
    'SAN_match' => 'www.github.com'
    'CN_match' => 'www.github.com'
]]);

$uri = 'https://www.github.com/';
file_get_contents($uri, FALSE, $ctx);
```

The patch is strict. I.E. it follows the spec and *will* fail your SSL
negotiation attempt (with a descriptive error message to explain why)
if the remote peer provided a list of SAN names and you didn't specify
an `SN_match` stream context option. If no SAN dNSNames are supplied
by the peer the routine will fallback to the CN_match if specified.
This behavior is emphasized with a *MUST* in the RFC (meaning PHP's
current implementation is NOT compliant). I'm happy to bring the
default behavior into line with the spec but we need to determine if
people are okay with making things secure by default. This seems like
a no-brainer to me as IMHO security should be prioritized over
simplicity:

> *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.

^^ 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?