Re: [VOTE] TLS Peer Verification

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