PHP 5.6 and SSL/TLS: Getting Better But Will PHP Programmers Actually Use It?
Some time ago I wrote all about the main risks in using SSL/TLS in PHP and here’s one of the more relevant quotes:
As much as I love PHP as a programming language, the briefest survey of popular open source libraries makes it very clear that Transport Layer Security related vulnerabilities are extremely common and, by extension, are tolerated by the PHP community for absolutely no good reason other than it’s easier to subject users to privacy-invading security violations than fix the underlying problem. This is backed up by PHP itself suffering from a very poor implementation of SSL/TLS in PHP Streams which are used by everything from socket based HTTP clients to file_get_contents() and other filesystem functions. This shortcoming is then exacerbated by the fact that the PHP [manual] makes no effort to discuss the security implications of SSL/TLS failures.
If you take nothing else from this section, my advice is to make sure that all HTTPS requests are performed using the CURL extension for PHP. This extension is configured to be secure by default and is backed up, in terms of expert peer review, by its large user base outside of PHP. Take this one simple step towards greater security and you will not regret it. A more ideal solution would be for PHP’s internal developers to wake up and apply the Secure By Default principle to its built-in SSL/TLS support.
Yes. My honest recommendation is that if you intend using a secure connection, for example a request over HTTPS, just don’t use PHP sockets or streams. The problems with PHP’s implementation are widely known but it’s perhaps captured best by the then inability of PHP’s SSL layer to verify a perfectly valid certificate using Subject Alternative Names as used for Packagist.org. Simply put, if nobody noticed that glaring flaw outside of one high profile case then they were never going to notice its less obvious shortcomings.
So, I was very excited to see the following commit on Github to PHP’s source code yesterday evening: https://github.com/php/php-src/commit/6edc84fcdfc8e76507bc73122310fff4b6170b88
This commit implements the TLS Peer Verification RFC for PHP 5.6 that was voted through (25-0) as 2013 drew to a close. The RFC reverses PHP’s course and provides PHP streams with defaults that enable both peer verification and host verification. The patch implements the RFC and it lets PHP leverage the local system’s own certificate stash (e.g. Debian’s ca-certificates) where possible to avoid PHP having to distribute a bundle of its own and while also assisting in backwards compatibility.
Once we have a PHP streams/sockets system with a passable level of default security, the rest will be left to programmers on the ground to change their practices. For example, back in March 2013, PHP 5.4.13 introduced a new SSL Context option “disable_compression” so that programmers could defend their applications against CRIME attacks which includes the more recent BREACH attack.
I hopped on Github this morning out of interest and ran a search for this context option. Bearing in mind that Github may be malfunctioning and that all viewers of these results may be hallucinating as a group, I was a bit alarmed at seeing one result. Just one. Out of all the PHP code publicly hosted on Github. One. If this search is in anyway accurate, it means that there is a vast body of PHP code (as in all of it using SSL/TLS over PHP streams/sockets except ONE) which is vulnerable to CRIME/BEAST attacks irrespective of the PHP version it runs on.
That’s not just sad, it’s just…just… Damn it! Let me try that search again. DAMN IT!
Seriously, dear readers, all the improvements to PHP’s SSL/TLS security dropping for PHP 5.6 mean absolutely NOTHING if programmers will not actually use them. So please, start your editors.
- Yahoo encryption mocked by many (news.techeye.net)
- Mass surveillance prompts IETF work on SSL deployment guidelines (computerworld.co.nz)