Re: [VOTE] TLS Peer Verification

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 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. > > 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. -- Ferenc Kovács @Tyr43l - http://tyrael.hu