Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72092
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.177 as permitted sender)
MIME-Version: 1.0
Date: Mon, 3 Feb 2014 13:08:26 -0500
Message-ID: <CAH8MpnnmKt2byQU8DcWetnK6W7GB9HuF3srea-ECwQ4RRe1SWQ@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b10caa5fdfde004f18468ba
Subject: Windows Peer Verification
From: rdlowrey@gmail.com (Daniel Lowrey)

--047d7b10caa5fdfde004f18468ba
Content-Type: text/plain; charset=ISO-8859-1

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). In sane distros we're able to take
advantage of the OS-managed cert stores without getting our hands dirty.
However, windows uses a different certificate format which first requires
conversion to .PEM for use with OpenSSL libs. 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. Further, this wouldn't be a particularly good solution for web
environments where we'd be duplicating all the certificate conversion work
in each request (as needed) if we rely on the OS to keep certificates
current. We could generate the converted certs in PEM format once, but then
you basically lose the benefits of updates courtesy of the OS when you do
that.

The options for dealing with this (as I see them) are:

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.

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.

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.

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.

I don't want people to feel like the original peer verification RFC was a
misrepresentation, so if necessary we can vote on exactly how to handle the
situation re: windows users in 5.6. Thoughts?

--047d7b10caa5fdfde004f18468ba--