Secure Sockets Layer (SSL) just can't catch a break these days. Everywhere we turn, it seems, SSL is being implicated in security problems.
We've seen attacks against root certificate authorities (CA). We've seen weaknesses in how SSL certificates are validated. And now, those weaknesses have been used to attack Apple's in-app purchase mechanism. As I pointed out in my September 2011 column, these things erode our trust in the systems on the Internet that we all rely on.
Certificate pinning might be one solution, though it isn't an easy pill to swallow.
First, let's review what happens with SSL.
Whenever an SSL connection attempt is made, two fundamental things are verified before the connection is allowed to proceed. First, the remote system's certificate is checked to ensure that it has been signed by a trusted root CA. Each system (or, in many cases, browser) maintains a list of trusted root CAs. Further, there is a hierarchical chain of digital signatures for valid SSL certificates, making it quite trivial to verify any SSL certificate to ensure that it is worthy of our trust.
Next, the SSL software verifies that the remote system's name matches the name in the certificate and vice versa. This is to make sure that an attacker hasn't stolen a valid certificate from one machine to run it on another, thereby having the ability to fraudulently open network connections.
This all sounds well and good, but much to Apple's chagrin, there is still an opportunity for an attacker to break the system. It requires a fairly complicated attack in which the attacker inserts a root CA certificate onto his system and tampers with the domain name system (DNS) in order to get it to return incorrect results. Then the attacker can effect a man-in-the-middle (MITM) attack on an otherwise secure SSL network connection. This is how Russian developer Alexey Borodin was recently able to trick iOS apps into accepting in-app purchases.
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.
The result is far from perfect, unfortunately. Certificate pinning won't work for all circumstances. Even when it does work, it hampers scalability as well as flexibility in our production environments -- any certificate change would potentially require pushing out a new version of the affected app, for example.
But it does indeed give us an effective bit of digital duct tape to hold our software together securely -- until a better solution can be developed.
With more than 20 years in the information security field, Kenneth van Wyk has worked at Carnegie Mellon University's CERT/CC, the U.S. Deptartment of Defense, Para-Protect and others. He has published two books on information security and is working on a third. He is the president and principal consultant at KRvW Associates LLC in Alexandria, Va.
Read more about security in Computerworld's Security Topic Center.