Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72096
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU7Euu1mQiJ-2n8r9hQjt9ShqRaiQAouP=FSFeV9OVdjwA@mail.gmail.com>
References: <CAH8MpnnmKt2byQU8DcWetnK6W7GB9HuF3srea-ECwQ4RRe1SWQ@mail.gmail.com>
	<CAEZPtU7Euu1mQiJ-2n8r9hQjt9ShqRaiQAouP=FSFeV9OVdjwA@mail.gmail.com>
Date: Mon, 3 Feb 2014 13:46:38 -0500
Message-ID: <CAH8Mpnnu0BqRmb1PmGjQLTWYA0mtGkJdniDbGbD1Nn+Fn30JZw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04289de3a68b6004f184f1c0
Subject: Re: [PHP-DEV] Windows Peer Verification
From: rdlowrey@gmail.com (Daniel Lowrey)

--f46d04289de3a68b6004f184f1c0
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 3, 2014 at 1:25 PM, Pierre Joye <pierre.php@gmail.com> wrote:

>> 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.

Sorry, I was unclear. It works out of the box in Mac and the *nix distros
where I tested. OpenSSL stopped shipping their own CA file long ago and
distros generally synthesize the location of certs with  OpenSSL compile
time. The Windows cert store uses a different format that can be converted
to the PEM format OpenSSL requires, but for reasons mentioned in my
original mail this is not really an ideal solution.

>> In sane distros

> Just because OpenSsl is not used does not mean it is insane, at some
> point I could even think the contrary :)

Again, apologies for being unclear. By "sane" I simply meant that distros
keep their certs up-to-date and the environment variables available to
OpenSSL at compile time reflect the location where the OS stores these
certs. A distro handing out openssl binaries without these cert locations
would be what I classify as "not sane." I'm not trying to imply Windows
inferiority; only difference. The lack of clarity is my fault.


>> 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.

Absolutely. And this is the point of my mail: how best to allow the most
secure and user-friendly experience for users implementing the native PHP
API which, for better or worse, relies on the open PEM format used by
openssl. For users who get their PHP as part of distro this largely is a
non-issue because it's handled by the OS. Again, I'm not claiming Windows
inferiority; only difference. With Mac/*nix we don't have to worry about it
because they're (currently) supporting OpenSSL-backed solutions. There's no
additional step required there.

> Again, please keep in mind that it is not a windows only problem. This
> issue has to be addressed on all supported platforms.

Once more, I will make sacrifices to the deity of Windows retribution for
the unintentional pejorative tone of my original mail :)

The only real question here is this:

***** Should we ship a CA file? *****

Personally, I say no. If people are going to programmatically use encrypted
stream transfers they need to at the very least understand the basics of
the CA system. We shouldn't subsidize insecurity, and it's trivially easy
to procure a CA file.

--f46d04289de3a68b6004f184f1c0--