Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69147
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.182 as permitted sender)
MIME-Version: 1.0
Date: Mon, 16 Sep 2013 09:58:38 -0400
Message-ID: <CAH8MpnnTGD0xAwG1j9sh10EC6XzdscVRLbJzEMG6qWSBK5c17w@mail.gmail.com>
To: johannes@schlueters.dot.de
Cc: addw@phcomp.dot.co.uk, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec519691de108f004e68099a5
Subject: Re: Re: PHP Crypt functions - security audit
From: rdlowrey@gmail.com (Daniel Lowrey)

--bcaec519691de108f004e68099a5
Content-Type: text/plain; charset=ISO-8859-1

> PHP itself doesn't do much crypto stuff. We rely mostly on libs like
> openssl etc. and provide hashing algorithms which follow the
> specifications. If the specifications are bad this is a global non-PHP
> issue.

That's all true, of course. But there are still places where new patches to
the underlying libs (like openssl) get lost in translation and it's PHP's
responsibility to add support. For example, about a year ago the CRIME
attack vector (
https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls)
was publicized. Preventing CRIME attacks is trival: disable compression at
the TLS layer. The OpenSSL folks quickly provided the SSL_OP_NO_COMPRESSION
constant in response, but it wasn't until a couple of months ago that I
supplied a patch (http://lxr.php.net/xref/PHP_5_5/ext/openssl/xp_ssl.c#398)
allowing a stream context option to disable compression on TLS streams.
This means that for ~8-9 months any PHP code using the native encryption
context options with `stream_socket_server()` was vulnerable.

Now, I'm aware that very few developers use PHP to develop heavy-duty
encrypted servers. Indeed there's a misconception that CLI PHP isn't
capable of functioning in long-running server environments (not true). In
such scenarios it doesn't help that PHP delegates the actual encryption to
other libs under the hood -- we still need to implement security fixes as
they become available.

Perhaps more importantly, it's incumbent upon PHP to keep documentation
up-to-date on these kinds of issues. The disable_compression ssl:// stream
context option used to prevent the CRIME attack (above) is still not
reflected in the php.net documentation ...

*** THIS IS MY FAULT ***

I should have submitted a docs patch as well, but failed to do so. I'll
make that happen this week.

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.

IMO education and documentation is an important step we can take on the
security front right now that's decoupled from any of the implementation
code. Security should be treated proactively and not reactively and this is
an area where improvement is necessary. I can't think of a better way to
generate bad press for PHP than to have PHP code publicly exploited. That
said, documenting things like this take time and we're all busy. I'll make
an effort myself to improve documentation (at least with regard to standard
SSL/TLS use-cases), but I'm only one person and I'm not a security expert
by any means. I think it's important for anyone familiar with this area to
also spend some time to see where the official documentation can be
improved and explained.

It's not enough to provide secure functionality -- we need to make sure its
possible for people to understand how to implement that functionality in a
secure way.

--bcaec519691de108f004e68099a5--