> 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.
