Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72100
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.169 as permitted sender)
MIME-Version: 1.0
Date: Mon, 3 Feb 2014 14:19:36 -0500
Message-ID: <CAH8Mpn=Kw9CCmpiXm-UE2s=GKFroTGczTr=ENczuAeiTCH6QwQ@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>, 
	swhitemanlistens-software@cypressintegrated.com
Content-Type: multipart/alternative; boundary=90e6ba613dd4870a7904f185679d
Subject: Re: Windows Peer Verification
From: rdlowrey@gmail.com (Daniel Lowrey)

--90e6ba613dd4870a7904f185679d
Content-Type: text/plain; charset=ISO-8859-1

> And anyway I'm not in agreement that if people are going to use
> outbound encryption -- if they are going to simply call a PHP function
> -- they need to understand how to update their local CA bundle. I
> would think that, the majority of the time, users are either [a]
> loading a provided "PHP binding" (.PHP file) for a public API or [b]
> copying-and-pasting boilerplate code from API documentation and, just
> speaking realistically, you should not expect them to know what's
> going on under the hood. You can have a relatively good understanding
> of HTTP (without the S) and when your service says "now you must use
> encryption" there shouldn't be a big learning curve on the user side.


I'm totally in agreement with everything you've said. There is no "learning
curve." The only thing required for a secure transfer in this case is the
knowledge that:

(1) You need a CA to verify that the other party is who they say they are
(2) As such, you have to tell PHP about the CA file(s) you want it to use.

There is nothing confusing or difficult about setting a single php.ini
value "openssl.cafile = C:\path\to\cacert.pem"

But there is something *very* wrong with allowing users to do this without
peer verification by default:

    file_get_contents('http://yourbankinginstitution.com');

The whole point of the recently accepted RFC and the new RFC on TLS
security is to eliminate the need for users to understand TLS to use these
features. There is no disagreement here and I'm not sure what you're
arguing here.

--90e6ba613dd4870a7904f185679d--