Frédéric Bastiat is famous for his assertion about the difference between good and bad economists. One translation reads:

Between a good and a bad economist this constitutes the whole difference - the one takes account of the visible effect; the other takes account both of the effects which are seen, and also of those which it is necessary to foresee. Now this difference is enormous, for it almost always happens that when the immediate consequence is favourable, the ultimate consequences are fatal, and the converse. Hence it follows that the bad economist pursues a small present good, which will be followed by a great evil to come, while the true economist pursues a great good to come, - at the risk of a small present evil. I believe that you could almost certainly replace the word "economist" in this paragraph with "security professional." Many of our present catastrophes stem from decisions made years (or decades) ago that simply did not take into account what was to come.

Of course, nothing is as simple as Bastiat proposes. As I have discussed before, foresight is always difficult. In fact, I have yet to hear of somebody that gets it consistently right (see Scott Adams' brilliant insights in this October 11th 1994 comic).

Still, we have to take our best shot and maybe we can learn something along the way. Despite the difficulties, we must ensure that our security research and development of today is not sacrificing long-term good for short-term benefits.

Consider the security technology known as "pinning." Most internet traffic between your browser and the websites you visit, or between apps on your mobile device and their back-end servers, is secured by TLS (Transport Layer Security). TLS is supposed to provide two essential security characteristics: privacy and authentication.

<!--more-->

Privacy simply means that only your computer and the computer you are connected to can read each other's messages. TLS provides privacy to the two parties through encryption. Suppose that you have browsed to your bank's website. You would very likely prefer that nobody else can read the messages going back and forth. Because encryption is what most non-technical people think of first when they think of "security", it's probably the concept that is easiest to explain.

But TLS is also supposed to provide authentication. It's great if your messages to your bank are encrypted, but that won't do you any good if you're not actually talking to your bank. It is essential that you know to whom you're computer is connected.

Accordingly, TLS uses a cryptographic certificate mechanism for authenticating the connecting parties. When your browser first connects to your bank, the bank transmits a piece of data called a "certificate." It includes the website's name (e.g., www.yourbank.com) along with some cryptographic data known as a signature provided by a trusted third party. Your browser can verify that the certificate is correctly signed by said third party, verify that the web address matches, and confirm to you that you are connected to the right party.

That's how it's supposed to work, but it breaks down all the time. Certificate management and trust can be corrupted or disabled, and the whole operation is too complex for average users to monitor and understand.

Pinning has been introduced as a way of solving this problem. The concept of a "pin" is simply to configure a browser or an app with a known, trusted certificate ahead of time. So, instead of trusting your bank's certificate if it's signed by a trusted party, you simply get a certificate directly from the bank and keep it stored in the browser. Apps can do this even better because the app can be distributed with the pinned certificate "baked in." Ideally, the app doesn't have to trust anyone else; it is simply distributed with all the information it needs right up front.

The security professional sees the immediate positive benefits:

Reduced need to trust Reduced risk of software vulnerability (simpler operations for fewer bugs) Reduced risk of misconfiguration

But, as Bastiat might say, to be good security professionals, we need to make sure that we are taking into consideration the long term effects. We need to envision the big picture.

Last year, security researchers from Germany conducted a study on the use of pinning in Android apps. They analyzed over 600,000 apps and found that less than 2% could be adapted as-is for certificate pinning (perhaps as high as 9% with relaxed constraints). The core problem with pinning is that it increases the difficulty in maintenance. With traditional TLS, if the server needs to deploy a new certificate, the entire process is automated and transparent. When the browser or app connects to the server, the new certificate is provided and, with the proper signature, accepted.

With pinning, a browser has to be manually updated by the user every time the server needs to use a new certificate. With apps, at least, the certificate is baked into the app and a new certificate can be deployed simply by updating the app through normal channels (e.g., the app store). Still, this is a recognized maintenance headache and one that most apps would have to be rewritten to support.

Looking beyond the immediate benefit of this solution, I am concerned that this is yet another example of disabling functionality in order to achieve security.

But the other issue raised by this study is that deciding when and how to use pinning is not simple after all. As they explained, for developers to successfully use pinning, they need to understand the difference between leaf and CA pinning, how the "target origin" will be determined for the lifetime of the app, how API's will use TLS, and management for the certificates. According to the authors, whether or not to use pinning had been based on "intuition" prior to their work and part of their contribution was a set of criteria for objectively choosing.

If all of this sounds complicated, it is. The authors of the study also interviewed app developers and found that almost all of them were not using pinning because of the complexity. The final contribution of this research project was a website for guiding developers through deciding on whether or not to use pinning and how to implement it.

In short, although there are some obvious immediate advantages to pinning, it also introduces non-trivial problems. It may be that pinning reduces complexity in one corner by simply pushing it to another. It may be that it reduces risks of third-party trust abuse by increasing vulnerabilities in the management and deployment of app-issued certs.

In my mind, it is too soon to determine the net impact of pinning. But identifying and analyzing the less obvious, less immediate impacts of a security "solution" are critical to our progress in the field.