Re: [VOTE] TLS Peer Verification

On Tue, Dec 17, 2013 at 8:56 AM, Ferenc Kovacs <tyra3l@gmail.com> 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 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 >>>>> 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 no 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 >>> only 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ács >>> @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 with >> 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 choice >> 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 already >> 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 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. > > > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > Just to clarify: I'm not saying it isn't a BC break. I'm saying that: 1. As BC breaks go this one is extremely mild; 2. I believe this is a security question that's important enough to answer with a BC break; 3. People have the option (through the vote to bundle a CA file) to influence how far-reaching the resulting BC break actually is.