| CARVIEW |
Select Language
HTTP/2 200
server: myracloud
date: Sun, 12 Oct 2025 16:42:44 GMT
content-type: text/html; charset=utf-8
content-length: 3509
vary: accept-encoding
content-encoding: gzip
expires: Sun, 12 Oct 2025 16:42:44 GMT
cache-control: max-age=0
etag: "myra-da4a98f1"
php.internals: Re: [VOTE] TLS Peer Verification
Re: [VOTE] TLS Peer Verification
From: Daniel Lowrey Date: Tue, 17 Dec 2013 02:03:40 +0000 Subject: Re: [VOTE] TLS Peer Verification References: 1 2 Groups: php.internals Request: Send a blank email to internals+get-70695@lists.php.net to get a copy of this message
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 >
Thread (29 messages)
| « previous | php.internals (#70695) | next » |
|---|