Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72095 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 93807 invoked from network); 3 Feb 2014 18:35:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Feb 2014 18:35:46 -0000 Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender) X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com X-Host-Fingerprint: 173.1.104.101 rproxy2-b-iv.figureone.com Received: from [173.1.104.101] ([173.1.104.101:64206] helo=rproxy2-b-iv.figureone.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 32/D9-35654-081EFE25 for ; Mon, 03 Feb 2014 13:35:45 -0500 Received: from bad.dop.co ([108.12.130.219]) by rproxy2-b-iv.figureone.com (Brand New Heavy v1.0) with ASMTP id PUM16340 for ; Mon, 03 Feb 2014 10:35:40 -0800 Date: Mon, 3 Feb 2014 13:35:22 -0500 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <5010377349.20140203133522@cypressintegrated.com> To: Daniel Lowrey In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Windows Peer Verification From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman) I'll accept this as a delayed *bump* of my last post on the topic. ;) > 1. Disable peer-verification by default in windows builds. Personally, I > don't see this as a valid option as it's terrifically insecure. I believe > it's better to fail with a warning than allow users to believe they're > conducting safe transfers when they're 100% vulnerable to Man-in-the-Middle > attacks. We can't have Windows swallowing the error while other OSes do not. Remember that not only do we have Windows production servers, but also people developing against local Windows installs but rolling out to other OSes. Also, the change applies not just to CAs in the public bundle but to private CAs that will now need to be manually trusted (on all OSes). You want to flag this problem as early as possible in development. I don't consider any lowered security restrictions on a Windows build (of the same PHP version) acceptable. That would be akin to prescribing PHP-Windows for "toy use only." > 2. Do nothing and document heavily. Peer verification failures will already > generate an informative error message. Beyond this, the steps required by a > windows user to make peer verification work by default are extremely simple: > - Download this file: http://curl.haxx.se/ca/cacert.pem (or equivalent) > - openssl.cafile = C:/path/to/cacert.pem (in php.ini) > Also, we could easily generate a painfully explicit E_WARNING in windows > explaining exactly how to fix the problem in the absence of the requisite > configuration. If [2] is necesssary, then we should accept the burden of being as verbose as possible. > 3. Include the same PEM-formatted CA file curl distributes with windows PHP > binaries and pre-populate the relevant php.ini directive. I don't *think* > this would come with any licensing issues as the curl cacert file is > licensed under the same licenses as the Mozilla source file it draws from > (MPL 1.1, GPL v2.0 or LGPL 2.1). However, I'm not an expert in these > matters, so others would likely need to comment. I have no idea about the licensing burdens, but [3] is vastly preferred if available. Encumbering Windows users with manual configuration when WPI is supposed to be a package managaer. Another related possibility (if it eases licensing worries somehow) is having a separate WPI package for "PHP CA Bundle" -- so it can be maintained + licensed + removed separately. I know you can make one WPI depend on another (like with the Windows Role/Feature manager et al.). -- Sandy