On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey <[email protected]> wrote:
> On 19 September 2013 10:52, Daniel Lowrey <[email protected]> wrote:
>>> *I consider this a bug* I understand that it's easier to code not verifying the
>>> peer, and the hostname may not be available when you are stacking ssl over a stream.
>>> But file_get_contents("https://...") is
>>> *precisely* the case that should work right
>>> out of the box.
>>
>> ^^ This.
>>
>> Before I can fully/cleanly implement these changes we need to decide
>> if PHP wants to move to a secure-by-default model for streams
>> utilizing the built in encryption wrappers. Thoughts?
>
> I think we should do this in 5.6. cURL has behaved this way for
> literally years at this point (verify by default, provide a switch to
> disable verification) and users seem to do just fine there. The much
> improved security story outweighs the (admittedly present) BC issues
> for mine.
>
> As for the CA bundle side of things, I wonder if this is one of those
> rare times where an ini setting might make sense, as opposed to actual
> bundling — that would allow distros to point to their packaged bundles
> without needing to patch php-src, and we could provide from-source
> installation instructions easily enough to point to common distro
> locations and the cURL download for users on more exotic OSes (like
> Windows).
Windows supports that very well, with Curl for example. It can also
uses the OS certificates database.
For the record here, curl has this setting already:
http://us2.php.net/manual/en/curl.configuration.php#ini.curl.cainfo
which is around for quite some time already.
It could be possible to share it with openssl, but back then I did not
check it out as only curl was concerned.
One thing I do not remember off hand is if we actually enable cert
validation per default with php's curl. It should be as we discussed
that already many times.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org