Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70697
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52B004E2.30607@php.net>
References: <CAH8Mpn=W6cuZtn5210+u7xZ+ejM22mk0Sq3tihbQ0qRtr-H=LA@mail.gmail.com>
	<52AFABF7.60105@sugarcrm.com>
	<CAH8MpnnuSh1RJ8=Ty8rhEqg1mfGdJD+hs63zm7jBR66iXYaVXg@mail.gmail.com>
	<52B004E2.30607@php.net>
Date: Tue, 17 Dec 2013 11:58:41 +0100
Message-ID: <CAH-PCH6vYL6jmCd-D=3qxTV_pqP_-9Qd2rENGtDENfS8i=6Qiw@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: PHP Internals <internals@lists.php.net>, Daniel Lowrey <rdlowrey@gmail.com>
Content-Type: multipart/alternative; boundary=001a1130d202b616d804edb8cffc
Subject: Re: [PHP-DEV] [VOTE] TLS Peer Verification
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a1130d202b616d804edb8cffc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 issu=
e!
>>
>> 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 t=
he
>> same https functionality they've always had. The only difference is that
>> 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 specifying
>> 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 thought
>> that many (most?) people using things like file_get_contents('https://')
>> are completely unaware of this issue in the first place. My thinking her=
e
>> is that instead of not saying anything and just giving these users a fal=
se
>> 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 appropriate
>> documentation. Should the RFC pass I'll work to make sure that any peer
>> 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 file
>>> 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 o=
f
>>> 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 get
>>> 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 worked, 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 engine
> 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 version, even
if they break BC.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a1130d202b616d804edb8cffc--