On the surface, it would seem that SSL's worthiness has just about run its course. Almost. But there may still be some digital duct tape we can apply to get a few more years out of this venerable protocol. That digital duct tape is known as certificate pinning.
With certificate pinning, a third test is performed on each network connection before it is allowed to proceed, verifying that the remote certificate is not just valid and that its host name matches, but also that it is the exact certificate we were expecting.
As you might figure, certificate pinning is especially well suited to a situation where an app can know in advance which certificate belongs to each server to which it needs to connect. Therein lies the major burden in using this technique.
In our software, we cannot rely on certificate pinning when we need to establish a secure connection to a system over which we have no oversight. Its certificates could change at any time, rendering our software incapable of making a connection.
Even for secure connections to our own servers, certificate pinning carries with it an administrative burden of its own. In our software, we are now required to maintain that list of certificates we trust -- not just the root CA certificates we trust, but the actual certificates.
In some fairly limited circumstances, this is a perfectly acceptable burden to bear. In others, it is just overly unwieldy to be useful.
What's more, it is a solution that is especially well suited to client systems that have their own computing power, such as mobile devices.
Thus, the ideal situation for certificate pinning lies in a mobile app connecting to its own server(s) that it knows about in advance. For those situations, certificate pinning presents a compelling additional hardening on top of standard SSL.
To use certificate pinning, every affected software developer will have to integrate the code into his apps. The good news is that we have several code examples illustrating how to use certificate pinning in iOS as well as Android apps. In Apple's in-app purchase case, Apple itself has released sample code for developers to integrate into their in-app purchase code base. These appear to be effective at thwarting MITM attacks.
This is a significant problem faced by today's SSL software. Indeed, in Apple's situation, its workaround required an unprecedented one-time exemption to its own policies. To implement the workaround, iOS developers are required (and allowed) to use a specific unpublished application programming interface (API). Apple says this will be properly fixed in iOS 6 when it is released, but for Apple to allow access to an unpublished API represents a major problem.