Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70708
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH8Mpnn2pYVXs6o7mYMqBo=cy6RwhkzCL==ivnTEFY-E4-EyVQ@mail.gmail.com>
References: <CAH8Mpn=W6cuZtn5210+u7xZ+ejM22mk0Sq3tihbQ0qRtr-H=LA@mail.gmail.com>
	<52AFABF7.60105@sugarcrm.com>
	<CAH8MpnnuSh1RJ8=Ty8rhEqg1mfGdJD+hs63zm7jBR66iXYaVXg@mail.gmail.com>
	<52B004E2.30607@php.net>
	<CAH-PCH6vYL6jmCd-D=3qxTV_pqP_-9Qd2rENGtDENfS8i=6Qiw@mail.gmail.com>
	<CAH8Mpnnbdn+hXw5R=m-qWexOmgR3+deSEE5a0vKhOQ=Rjf5egw@mail.gmail.com>
	<52B041E5.9070903@php.net>
	<CAH-PCH5Hnm0TBQSs+DCF2xLVoUY1QeNqWMBnb1Y6JkKvP9_dBA@mail.gmail.com>
	<CAH8Mpnn2pYVXs6o7mYMqBo=cy6RwhkzCL==ivnTEFY-E4-EyVQ@mail.gmail.com>
Date: Tue, 17 Dec 2013 14:56:07 +0100
Message-ID: <CAH-PCH43gLG_QpiioJkwYA0KqHpEwWNHwSQMhaHHbkvhgHU4vg@mail.gmail.com>
To: Daniel Lowrey <rdlowrey@gmail.com>
Cc: Joe Watkins <krakjoe@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1136739a4a384c04edbb4ac9
Subject: Re: [PHP-DEV] [VOTE] TLS Peer Verification
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a1136739a4a384c04edbb4ac9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 17, 2013 at 2:19 PM, Daniel Lowrey <rdlowrey@gmail.com> wrote:

> On Tue, Dec 17, 2013 at 7:36 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
>>
>>
>>
>> On Tue, Dec 17, 2013 at 1:21 PM, Joe Watkins <krakjoe@php.net> wrote:
>>
>>> On 12/17/2013 12:08 PM, Daniel Lowrey wrote:
>>>
>>>> given that this is a security related change, one could argue that
>>>>>
>>>> security
>>>>
>>>>> fixes should be ok to go in a minor version, even if they break BC.
>>>>>
>>>>
>>>> This was my thought process. In my mind the RFC is about improving
>>>> security
>>>> for users who don't know any better. I'm hoping to avoid the "Are we
>>>> allowed to break BC?" discussion.
>>>>
>>>
>>> Okay, but nobody is asking the question "are we allowed to break
>>> compatiblity for no good reason", because it's a silly question.
>>>
>>>
>>>
>>>> Adding a CA file to the distribution is exceedingly simple, but this i=
s
>>>> not
>>>> a silver bullet. For example, the Mozilla CA file used by cURL is
>>>> usually
>>>> updated three or four times a year. Even when bundling a CA file it
>>>> would
>>>> only be a matter of time before a distribution's version was out of
>>>> date.
>>>> In the end we can only do so much before users must bear the weight of
>>>> maintaining an acceptable level of security themselves.
>>>>
>>>>
>>>>
>>> So then bundle it, doing something is much better than doing nothing,
>>> there are plenty of opportunities to update the cafile with minor versi=
ons,
>>> the package maintainers will likely solve the stale cafile problem for =
us
>>> on the major distributions, when they see we are actually doing somethi=
ng
>>> about it ...
>>>
>>> It really does not seem sensible to purposefully break compatibility
>>> when it can be retained easily, the vote is going to be split with no c=
lear
>>> outcome doing no good for anyone. Reduce the options to two if you want=
 to
>>> actually move forward.
>>>
>>> That's enough from me, gonna go find something to break :)
>>>
>>>
>> Don't forget that bundling a CA file also means that take the burden of
>> keeping it up-to-date to our shoulders.
>> I'm not saying that we shouldn't do it, but if we do then we have to mak=
e
>> sure that we understand the implications.
>> Even if we take the "easy" path, and select an already existing CA bundl=
e
>> (eg. Mozilla), we have to make sure to always ship the up-to-date versio=
n
>> and there could be events, when we would need to create a release only
>> because some CA incident (like what happened with DigiNotar in 2011 whic=
h
>> forced the everybody shipping CA bundles to update their bundle to remov=
e
>> this CA from it's list of trusted CAs).
>> As I've said, I'm only stating this so everybody can understand the
>> implications before voting.
>>
>> --
>> Ferenc Kov=C3=A1cs
>> @Tyr43l - http://tyrael.hu
>>
>
>
> Regarding the alteration of voting options Joe requested ...
>
> I do believe approving the patch without bundling a CA file is a valid
> option. As Ferenc mentioned there are potential maintenance issues with
> including a CA file and I do not feel comfortable forcing the hand of the
> release managers on this point. The vote exists between "yes" and "yes wi=
th
> a bundled file" for this reason to tease out what's best for PHP in this
> scenario. Please make sure you understand the ramifications of your choic=
e
> before voting.
>
> I do want to preemptively address the idea that not including a CA file
> would somehow cause disastrous BC breakage. In my opinion this could not =
be
> further from the truth. APIs are not changing. The return value is alread=
y
> FALSE with a warning generated on a connection or transfer failure. Code
> should already have error checking in place for this potential scenario
> because socket transfers are never guaranteed (maybe your ethernet cable =
is
> unplugged).
>
> The only difference this patch makes is to expand the reasons why a
> transfer can return FALSE with an E_WARNING to include "you're doing
> something dangerous." As far as BC breakage goes, this is as
> backward-compatible as a BC break could possibly be.
>
>
I wouldn't say it isn't a BC break, as there are a plenty of code out there
which could/will break after this change.

   - If we don't ship/include a CA bundle, every stream connection for
   ssl://, https:// or ftps:// resource will fail before the user changes
   his/her php.ini
   - even if we do include a CA bundle, there are a bunch of code which
   connects to https:// urls using self-signed certs, and for some of
   those, there is no CA file available, so you won't be able to get your c=
ode
   functioning again without rewriting your code to explicitly disable peer
   verification.

Those are BC breaks, and I'm pretty sure that this would/will affect a lot
of users.
But I do think, that in this case the BC break could be acceptable, so I'm
looking forward to the results.



--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a1136739a4a384c04edbb4ac9--