| CARVIEW |
Select Language
HTTP/2 200
server: myracloud
date: Mon, 13 Oct 2025 07:40:19 GMT
content-type: text/html; charset=utf-8
content-length: 4765
vary: accept-encoding
content-encoding: gzip
expires: Mon, 13 Oct 2025 07:40:19 GMT
cache-control: max-age=0
etag: "myra-b7ad2810"
php.internals: Re: [VOTE] TLS Peer Verification
Re: [VOTE] TLS Peer Verification
From: Ferenc Kovacs Date: Tue, 17 Dec 2013 11:40:30 +0000 Subject: Re: [VOTE] TLS Peer Verification References: 1 2 3 4 5 6 Groups: php.internals Request: Send a blank email to internals+get-70699@lists.php.net to get a copy of this message
On Tue, Dec 17, 2013 at 12:27 PM, Joe Watkins <krakjoe@php.net> wrote: > On 12/17/2013 10:58 AM, Ferenc Kovacs wrote: > >> 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: https://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: https://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. -- Ferenc Kovács @Tyr43l - https://tyrael.hu
Thread (29 messages)
| « previous | php.internals (#70699) | next » |
|---|