Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70711
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52B0597F.600@lerdorf.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>
	<CAH-PCH43gLG_QpiioJkwYA0KqHpEwWNHwSQMhaHHbkvhgHU4vg@mail.gmail.com>
	<52B0597F.600@lerdorf.com>
Date: Tue, 17 Dec 2013 15:06:53 +0100
Message-ID: <CAH-PCH51eNm3K6Nia5N7LSeN6FBpV88=5ZE8hK3EqFQ3w0u1Xw@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Daniel Lowrey <rdlowrey@gmail.com>, Joe Watkins <krakjoe@php.net>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bd6adbccce2f804edbb7095
Subject: Re: [PHP-DEV] [VOTE] TLS Peer Verification
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7bd6adbccce2f804edbb7095
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 17, 2013 at 3:02 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> On 12/17/2013 08:56 AM, Ferenc Kovacs wrote:
> > 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 w=
e
> >>>>> 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 thi=
s
> is
> >>>>> 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
> versions,
> >>>> the package maintainers will likely solve the stale cafile problem
> for us
> >>>> on the major distributions, when they see we are actually doing
> something
> >>>> 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 n=
o
> clear
> >>>> 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
> make
> >>> sure that we understand the implications.
> >>> Even if we take the "easy" path, and select an already existing CA
> bundle
> >>> (eg. Mozilla), we have to make sure to always ship the up-to-date
> version
> >>> and there could be events, when we would need to create a release onl=
y
> >>> because some CA incident (like what happened with DigiNotar in 2011
> which
> >>> forced the everybody shipping CA bundles to update their bundle to
> remove
> >>> 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 wit=
h
> >> 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
> with
> >> a bundled file" for this reason to tease out what's best for PHP in th=
is
> >> scenario. Please make sure you understand the ramifications of your
> choice
> >> before voting.
> >>
> >> I do want to preemptively address the idea that not including a CA fil=
e
> >> 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
> already
> >> FALSE with a warning generated on a connection or transfer failure. Co=
de
> >> should already have error checking in place for this potential scenari=
o
> >> 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 code
> >    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.
>
> Note that the distro maintainers tend to hate when we bundle stuff like
> this. We have this same situation with the Olsen tz. They much prefer
> having a single place to update resources that are needed by multiple
> applications like the ca cert bundle and the Olsen tz db. So, for most
> of our users (assuming most of our users rely on distro-packaged
> versions of php) I don't think it actually matters whether we ship the
> ca bundle or not. The distros are going override this decision and point
> to the distro-level bundle much like many of them have done with the
> timezone file.
>
> -Rasmus
>

True, distros would prefer their own bundle, what I was saying above, that
even though most people would be covered by the distros, there will be
people, who will notice the BC break: either because they roll their own
php or because they use a distribution which doesn't provide a CA by
default, or ultimately because they are sites out there, which uses certs
not signed by CAs included in the major CA bundles.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7bd6adbccce2f804edbb7095--