In his latest post Pádraic Brady shares his thoughts about the state of TLS/SSL functionality in PHP and how he thinks developers should avoid the trap of "lowest common denominator" and opt for insecurity.

A few weeks back I wrote a piece about updating PHARs in-situ, what we’ve taken to calling “self-updating”. In that article, I touched on making Transport Layer Security (TLS, formerly SSL) enforcement one of the central objectives of a self-updating process. In several other discussions, I started using the phrase “Lowest Common Insecure Denominator” as a label for when a process, which should be subject to TLS verification, has that verification omitted or disabled to serve a category of user with poorly configured PHP installations.

This is not a novel or even TLS-only concept. All that the phrase means is that, to maximise users and minimise friction, programmers will be forever motivated to do away with security features that a significant minority cannot support by default.

He goes on to talk about how, in some places, targeting the lowest common denominator is okay, security isn't one of them. He also includes four basic concepts developers can adhere to to prevent this targeting:

• You should never knowingly distribute insecure code.
• You should accept responsibility for reported vulnerabilities.
• You should make every effort to fix vulnerabilities within a reasonable time.
• You should responsibly disclose vulnerabilities and fixes to the public.

He follows these up with three steps you can follow to migrate an insecure architecture into something much more robust. This includes identifying the consequences of the update and documenting the solutions you've chosen, be those configuration updates or library changes.

Pádraic Brady has a new article on his site talking about the secure distribution of phars (PHP archive files) including some of the common pitfalls and potential solutions.

The PHAR ecosystem has become a separate distribution mechanism for PHP code, distinct from what we usually consider PHP packages via PEAR and Composer. However, they still suffer from all of the same problems, namely the persisting whiff of security weaknesses in how their distribution is designed. [...] [Several security-related issues introduce an element of risk that the code you receive is not actually the code the author intended to distribute, i.e. it may decide to go do some crazy things that spell bad news when executed.

He shares some of the steps he's taken to secure his own phar for a CLI application with things like:

• Distribute the PHAR over HTTPS
• Enforce TLS verification
• Sign your PHAR with a private key
• Avoid PHAR Installer scripts
• Manage Self-Updates securely

He finishes the post with one of the most important parts of the article - a reminder to do all of the things on the list above consistently.

This is not an outrageous outcome to introducing proper security on PHAR downloads. Go forth and do it for all PHARs. Help create an environment where distributing and installing code in secure ways is the normal expected thing to do.

Pádraic Brady has a new post today sharing a tool he's created to enhance the current PHP file_get_contents function with a safer, more secure alternative, the humbug_get_contents library.

With the release of PHP 5.6, there was a significant security improvement in how PHP handled SSL/TLS protections, namely that it enabled a secure set of default options. Previously, SSL/TLS was disabled by default. No peer verification, no certificate checking, and a lack of configuration options had combined to create a serious problem. You can find this problem easily by searching for file_get_contents() on github and locating a call to this function used to retrieve any HTTP resource while also having zero configuration.

An excellent example of this is Composer which uses file_get_contents() instead of curl to ensure maximum compatibility with using systems. Of course, this beggars a question. If all the SSL/TLS protections are off by default in PHP 5.3-5.5…what’s stopping some irksome hacker from injecting bad code into our Composer downloads? Answer: Nothing.

The package provides a drop-in solution to the possible man-in-the-middle issues that could be caused by the native functionality. It enhances the current function with additional TLS/SSL checking for HTTPS requests on current PHP versions.

Pádraic Brady has a new "let’s watch Paddy think aloud in a completely unstructured manner blog post" about the future of security when it comes to the popular PHP package manager Composer. It's recently come under criticism around its lack of package signing and TLS/SSL support.

The Composer issue, as initially reported by Kevin McArthur, was fairly simple. Since no download connection by Composer was properly secured using SSL/TLS then an attacker could, with the assistance of a Man-In-The-Middle (MITM) attack, substitute the package you wanted to download with a modified version that communicated with the attacker’s server. They could, for example, plant a line of code which sends the contents of $_POST to the attacker’s server.

He's been working on some updates to the project, one of with is TLS/SSL support as defined in this pull request currently pending. It enables peer verification by default, follows PHP 5.6 TLS recommendations and uses local system certificates in the connection. He talks some about other additional TLS/SSL measures that could be added in the future and how, despite it being safer than nothing, TLS/SSL is not the "cure all" for the problem.

He then moves on to package signing and suggests one method for implementation - signing the "composer.phar" executable and signing "everything else" (packages to be downloaded) to verify their validity.

The flaw in Composer’s installer isn’t that it’s unsigned, it’s that it doesn’t afford the opportunity for the downloader to read it before it gets piped to PHP. It’s a documentation issue. You can go down the route of using a CA, of course, but that’s further down the rabbit hole than may be necessary. Signing the composer.phar file is another matter.

In his latest post Pádraic Brady looks at a new addition to PHP (well, to be included in the next release) related to the SSL/TLS handling it provides in streams. He's happy to report that things are improving. This commit integrated an RFC allowing for TLS perr verification in PHP streams.

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.

With this new functionality coming in PHP 5.6, he strongly encourages developers to change how they're currently doing things and embrace this new verification to keep their code safer.

Joshua Thijssen has posted a walk-through of some work he's done to create a TLS decoder in PHP. TLS (Transport Layer Security) is a method for encrypting data being sent back and forth between the client and server, similar to how SSL is used.

As a proof of concept I wanted to see in how far I could decode some TLS data on the client side. Obviously, this is very complex matter, and even though TLS looks deceptively simple, it isn’t. To make matters worse, PHP isn’t quite helping us making things easy neither.

His solution (code posted here) goes through a few steps to finally get to the actual data:

• Capturing TLS data
• Gathering all the necessary fields
• From pre-master-secret to master-secret (decoding TLS_RSA_WITH_RC4_128_SHA)
• Partitioning our master-secret
• Decoding our data
• Verifying message integrity

For each step along the way he shares the relevant code and a brief description of what's happening. If you want to see the end result and try it out for yourself, check out his repository.

As is mentioned in this new post to the Symfony blog, the latest milestone release of the popular framework has been made - Symfony 2.3.0.

We were all waiting for it and many of us have been working hard for the last four years to make it happen. Today, Symfony 2.3.0 is available and this is the first long-term support release for Symfony version 2. I'm so happy that we were able to achieve this important milestone in the life of the framework. THANK YOU for making it possible. [...] That gives us the best of two different worlds: small teams and agile companies can benefit from the latest features by upgrading every six months (they have two months to upgrade); large teams and traditional companies can standardize on a release. [...] And 2.3.0 is our first long term support release. We, the community, are going to maintain it for the next three years (until May 2016).

The post includes some statistics about this latest release as well as some of the new features that come along with it. For those that want to upgrade right away, there's also some instructions on what to change in your "composer.json" file to try it all out.

On the PHPBuilder.com site today there's a new tutorial posted from Octavia Anghel about creating a login for your site that's powered by Ajax and uses a bit more security than normal. It includes hooks to use the Ajax Server Secure Layer or an OpenSSL connection.

In this article you will learn how to write a login application in PHP using Ajax and SSL/TLS in two ways either using aSSL (Ajax Server Secure Layer), a library that implements a technology similar to SSL without HTTPS or a simple Ajax and OpenSSL, an open source implementation of the SSL and TLS protocols.

They start with the aSSL method and link you to a download of the tool as well as some sample code to help you get started passing data to it via the session. The second example shows the OpenSSL method, mostly consisting of checking on the server side of the certificate that's passed along with the request.