Ángel González wrote:
> On 16/09/13 15:58, Daniel Lowrey wrote:
>> More generally, PHP's stream encryption aspects are quite poorly
>> documented. For example, https:// streams disable peer verification
>> by
>> default. While I understand that this is necessary to provide the easiest
>> possible user experience for things like `file_get_contents("
>> https://somesite.com")`, it's also
>> horribly insecure. 99% of people using
>> tools like this won't know anything about this "feature" and won't
>> realize
>> that their stream transfers are totally vulnerable to Man-in-the-Middle
>> attacks by default.
> Count me as one of those that didn't know https:// streams
> didn't verify
> certificates. :)
While we're on the topic, it's actually worse than that. Even if you
turn peer validation and name checking on, PHP can't handle
subjectAltNames in certificates, which causes quite a few failures.
(For example: GitHub's certificate is for *.github.com, but the
subjectAltName contains *.github.com and github.com so they can use a
single certificate. PHP will hence believe that github.com does not have
a valid certificate.)
I recently had to work around this in userland:
https://github.com/rmccue/Requests/pull/63
and
http://core.trac.wordpress.org/ticket/25007 -
which to my knowledge, are
the only HTTP clients in userland that go this far for validation.
--
Ryan McCue
<http://ryanmccue.info/>