Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70702
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH8Mpnnbdn+hXw5R=m-qWexOmgR3+deSEE5a0vKhOQ=Rjf5egw@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>
Date: Tue, 17 Dec 2013 07:10:06 -0500
Message-ID: <CAH8MpnmKxr-Oo8jnkoh47RSwG=i_17XcuEHtV3YimbQspVdEyw@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Joe Watkins <krakjoe@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b41402e1bc95404edb9cfc9
Subject: Re: [PHP-DEV] [VOTE] TLS Peer Verification
From: rdlowrey@gmail.com (Daniel Lowrey)

--047d7b41402e1bc95404edb9cfc9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I've been asked to extend the voting period by a week because: holidays. So
instead of Dec. 24 the voting period will now end on Dec. 31.


On Tue, Dec 17, 2013 at 7:08 AM, Daniel Lowrey <rdlowrey@gmail.com> 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 "Ar=
e
> we allowed to break BC?" discussion.
>
> Adding a CA file to the distribution is exceedingly simple, but this 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.
>
>
>
>
> On Tue, Dec 17, 2013 at 5:58 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
>>
>>
>>
>> On Tue, Dec 17, 2013 at 9:01 AM, Joe Watkins <krakjoe@php.net> wrote:
>>
>>> On 12/17/2013 02:03 AM, Daniel Lowrey wrote:
>>>
>>>> Thanks for the input -- I'm just happy people are interested in the
>>>> issue!
>>>>
>>>> Let me address a couple of things ...
>>>>
>>>>  you get essentially a configuration that can not use https at all
>>>>>
>>>>
>>>> I wouldn't say this is the really the case. Users still have access to
>>>> the
>>>> same https functionality they've always had. The only difference is th=
at
>>>> they now must explicitly acknowledge that, "Yes, what I'm doing is
>>>> insecure. I'm aware of it and I choose to continue anyway by specifyin=
g
>>>> this context option."
>>>>
>>>>  But it may be against the spirit of the RFC?
>>>>>
>>>>
>>>> :) Yes ... that's kind of what I'm going for. Basically it's my though=
t
>>>> that many (most?) people using things like file_get_contents('https://
>>>> ')
>>>> are completely unaware of this issue in the first place. My thinking
>>>> here
>>>> is that instead of not saying anything and just giving these users a
>>>> false
>>>> sense of security we should at least make mention of the problem
>>>> instead of
>>>> sweeping it under the rug.
>>>>
>>>>  people would still ignore it
>>>>>
>>>>
>>>> Almost certainly. In fact, users do this routinely with curl_* because
>>>> they
>>>> don't know any better.
>>>>
>>>> Finally, I think this problem can largely be alleviated with appropria=
te
>>>> documentation. Should the RFC pass I'll work to make sure that any pee=
r
>>>> verification changes are *well-documented* to (hopefully) stem the
>>>> inevitable storm of bug reports.
>>>>
>>>>
>>>> On Mon, Dec 16, 2013 at 8:42 PM, Stas Malyshev <smalyshev@sugarcrm.com
>>>> >wrote:
>>>>
>>>>  Hi!
>>>>>
>>>>>  Please throw your votes at the TLS Peer Verification proposal:
>>>>>>
>>>>>> https://wiki.php.net/rfc/tls-peer-verification
>>>>>>
>>>>>> Voting closes Dec. 24 ... Happy Holidays!
>>>>>>
>>>>>
>>>>> I'm not sure what to vote for here, because I like the ideas in the
>>>>> patch about having a setting for CAfile, which in many distros would =
by
>>>>> default enable peer verification and thus make you more secure, but I
>>>>> don't like the fact that when you compile PHP, you get essentially a
>>>>> configuration that can not use https at all, since you have no CA fil=
e
>>>>> configured.
>>>>> I'd like it more if there was an option where if you set cafile or
>>>>> capath, you get automatic peer verification, but if you don't, you do
>>>>> not have it. But it may be against the spirit of the RFC?
>>>>> I know you propose a warning in this case, but judging from the story
>>>>> of
>>>>> the datetime timezone warning, people would still ignore it. Also
>>>>> warning is not much help if for some reason you don't know where to g=
et
>>>>> a cert file. And there's no way to disable peer verification on ini
>>>>> level.
>>>>> --
>>>>> Stanislav Malyshev, Software Architect
>>>>> SugarCRM: http://www.sugarcrm.com/
>>>>> (408)454-6900 ext. 227
>>>>>
>>>>>
>>>>
>>> Morning Internalz,
>>>
>>>         Daniel, you have to assume that nobody will even read the
>>> manual; because they will not. I'm up for making it safer, but not for
>>> breaking anything at all in a minor version, if we do not bundle the CA
>>> file it would appear to break a bunch of requests that previously worke=
d,
>>> that doesn't seem good enough to me.
>>>         We can change the behaviour of the engine, but we cannot change
>>> the behaviour of users code; if a requests works now, regardless of it'=
s
>>> security, it must continue to work with the default settings, therefore=
, I
>>> suggest that you remove the option to change the behaviour of the engin=
e
>>> without maintaining the behaviour of users code, if the aim is to make
>>> these requests more secure by default, then allowing it to fail, by any
>>> means, defeats the object of making any changes at all.
>>>
>>>         If I'm wrong, tell me how :)
>>>
>>> Cheers
>>> Joe
>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>> I'm not taking sides, but given that this is a security related change,
>> one could argue that security fixes should be ok to go in a minor versio=
n,
>> even if they break BC.
>>
>> --
>> Ferenc Kov=E1cs
>> @Tyr43l - http://tyrael.hu
>>
>
>

--047d7b41402e1bc95404edb9cfc9--