Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72094
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH8MpnnmKt2byQU8DcWetnK6W7GB9HuF3srea-ECwQ4RRe1SWQ@mail.gmail.com>
References: <CAH8MpnnmKt2byQU8DcWetnK6W7GB9HuF3srea-ECwQ4RRe1SWQ@mail.gmail.com>
Date: Mon, 3 Feb 2014 19:25:33 +0100
Message-ID: <CAEZPtU7Euu1mQiJ-2n8r9hQjt9ShqRaiQAouP=FSFeV9OVdjwA@mail.gmail.com>
To: Daniel Lowrey <rdlowrey@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Windows Peer Verification
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Mon, Feb 3, 2014 at 7:08 PM, Daniel Lowrey <rdlowrey@gmail.com> wrote:

> I was playing with the most recent snap builds and, as expected, the
> openssl delegation to OS maintained certificate stores does not work in
> windows (like it does everywhere else).

Please define everywhere else. Last time I checked OpenSsl does not
support WIndows CA store. One has to fetch the binary cert from the
store and parse it using Openssl.

> In sane distros

Just because OpenSsl is not used does not mean it is insane, at some
point I could even think the contrary :)


> However, windows uses a different certificate format which first requires
> conversion to .PEM for use with OpenSSL libs.

Right, except with projects like curl, they provide SSL backend using
the native Windows SSL APIs. Sadly it cannot be used in parallel.

> It *is* possible to load
> certs from the windows store at runtime and perform the conversion, however
> I'm unfamiliar with the relevant APIs for interfacing with the windows cert
> store and wouldn't feel comfortable implementing in the remaining pre-5.6
> time-frame.

It also has a performance cost. I am not sure it is worth it as
everything in php relies on OpenSsl right now.


> 1. Disable peer-verification by default in windows builds.

I do not like this idea :) But we have discussed that already back
then. We will bundled the CURL cert file and we have to document where
to fetch it (no matter the OSes btw).

> 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)

We have to do this step anyway. And again, it is not a Windows problem
but a general problem, the CA DB has to be updated regularly and from
there (or any trusted source)


> 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.

We have to generate one if no valid DB can be found, no matter the OS.
Remember that it is possible to specify a CA file with Curl, we may
think about introducing this setting for php at large, thoughts?


> 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.

There is no licensing issue here. No worry :)

> Obviously, we want to avoid a 5.6 release with confused/upset Windows users
> whose https:// transfers no longer work as before. However, the simple fact
> is that the code that worked previously shouldn't have worked as it was a
> massive security problem.

Again, please keep in mind that it is not a windows only problem. This
issue has to be addressed on all supported platforms.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org