Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70700 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56358 invoked from network); 17 Dec 2013 11:52:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Dec 2013 11:52:01 -0000 X-Host-Fingerprint: 80.4.21.210 cpc22-asfd3-2-0-cust209.1-2.cable.virginm.net Received: from [80.4.21.210] ([80.4.21.210:29457] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A9/DB-32483-EDA30B25 for ; Tue, 17 Dec 2013 06:51:59 -0500 To: internals@lists.php.net,Ferenc Kovacs Message-ID: <52B03ADB.9050703@php.net> Date: Tue, 17 Dec 2013 11:51:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 References: <52AFABF7.60105@sugarcrm.com> <52B004E2.30607@php.net> <52B03511.8040603@php.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 80.4.21.210 Subject: Re: [PHP-DEV] [VOTE] TLS Peer Verification From: krakjoe@php.net (Joe Watkins) On 12/17/2013 11:40 AM, Ferenc Kovacs wrote: > On Tue, Dec 17, 2013 at 12:27 PM, Joe Watkins wrote: > >> On 12/17/2013 10:58 AM, Ferenc Kovacs wrote: >> >>> On Tue, Dec 17, 2013 at 9:01 AM, Joe Watkins 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 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 >>>>> 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 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 >>>> >>>>>> 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 >>>>>> 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 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. >>> >>> Tyrael, >> >> Okay, but there's no good reason not to implement the fix in the >> most backward compatible manner in the first place; breaking BC doesn't >> make it any more secure, it just breaks shit. >> Additionally when you consider the context, this is not affecting >> the behaviour of some rarely used functionality, it would be reckless to >> change it's behaviour when retaining compatibly is no problem at all. >> >> Cheers >> Joe >> > > Hi Joe, > > As I mentioned, I'm not saying that we should accept the proposal, I only > replied because you stated that > "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." > > Ofc. I also would prefer if we could improve the situation without > introducing a BC break in a minor version. > Hi Tyrael, I'm saying that we should, definitely, accept the patch; in this specific case we can fix the implementation or security issue without affecting behaviour, so I question whether it is useful or productive to have a voting option to integrate a fix that changes the behaviour of very widely used functionality when it's current behaviour can be retained and made secure by the proposal. I think it would be much better to remove the option to vote in favour of breaking compatibility since there is no logical reason, or otherwise genuine need to do so. Cheers Joe