TACK: TLS key pinning for everyone

Moxie Marlinspike and Trevor Perrin have created a TLS enhancement called Trust Assertions for Certificate Keys (TACK) that is designed to protect users against SSL certificate fraud with minimal overhead or infrastructure. The TACK proposal has been submitted to the IETF, as has a competing key-pinning mechanism created by Google's Chrome team. Although the two systems share broad similarities, their implementations are quite different.

The trouble

TACK is designed to combat flaws with the certificate authority (CA) trust chain model used by applications to check the validity of a remote site's TLS public key. The entire CA chain can be undermined by one bad CA, but there are other difficulties, too. First, any given hostname (e.g., www.example.net) can map to several different servers, with several certificate and thus several different CA chains deployed at once (e.g., in different jurisdictions) — which makes it harder to verify a connection. Second, the CA chain itself may change at any time, due to CA actions that are outside the control of the www.example.net site administrators.

There have been plenty of previous approaches to circumventing CA problems (including Marlinspike's own Convergence). "Certificate pinning" is a client-side technique in which the browser remembers (or "pins") a known-good SSL certificate across multiple browser sessions, and alerts the user if the certificate suddenly seems to change. The TACK proposal argues that certificate pinning is flawed because it binds the trust not to the server's TLS key but to the certificate, which includes the key plus the CA's signature and various other metadata. Thus, by extension, pinning the entire certificate ties trust of the server's TLS key to trust of the CA.

Google Chrome added a key-pinning feature (which tracks known-good TLS keys, even though it is often erroneously referred to as "certificate pinning") with Chrome 13 in mid-2011. But the TACK project says that this, too, has its flaws. First, Chrome's key-pinning uses a whitelist approach, with the browser designating specific CAs as trustworthy. But as long as the CA chain includes a whitelisted CA anywhere in the chain, the whole chain is trusted. Second, if a server issues a new TLS key, it does not roll out to users until a new version of Chrome is released.

TACK

In TACK, the identity-verification mechanism is also key-pinning, but rather than pinning a CA key, the browser pins a special "TACK" data structure created and controlled independently by the web site's administrators. The TACK includes a cryptographic signature of the site's TLS key, plus a public encryption key that the browser can use to verify the signature. Obviously the TACK public key and the TLS public key need to be different. In addition to this basic identity information, the TACK also includes an expiration date and a "generation" counter that gets incremented every time the site administrator creates a new TACK (so that old TACKs can be revoked if necessary). The final piece of the puzzle is that TACK is an extension to TLS itself, rather than an extension to HTTP as in Google's pinning proposal.

In practice, when the client application initiates a TLS connection, it requests a TACK from the server as part of the handshake step. When the server sends a TACK back in return, the client checks the generation information against its current cache for the site (if it has one), checks the expiration date, and validates the signature. If everything checks out, the TACK is "pinned" locally for future reference. The client can still choose to verify the CA chain or use other means to cross-check the identity of the server.

When the client pins a TACK, it is supposed to assign a cache lifespan to it equal to the amount of time between when it first saw the TACK and the present — up to a maximum of 30 days. In other words, a TACK that was first encountered seven days ago gets pinned for another seven days, while a TACK from one year ago gets the 30-day maximum. In the maximum-lifespan case, however, the TACK will only remain in the local cache if the user has returned to the site at least once every 30 days; otherwise it will have expired on the 31st day and a new pin will be created.

The big drawback of the TACK mechanism is that, like other client-side key-pinning methods, it does not protect the user against a man-in-the-middle (MITM) attack during the very first connection attempt to the remote server. It relies on the client having known-good information pinned locally. On the other hand, the TACK generation, cache lifespan, and expiration date features are intended to mitigate the damage that a MITM attack can inflict.

The worst-case scenario is a bad pin that lingers for 30 days, which is half the time the rogue google.com certificate issued by DigiNotar lingered in 2011 — and it could have lasted much longer had it not been discovered. Another advantage of TACK's design is that in the worst-case scenario, the server administrator can single-handedly push out an update, rather waiting on the CA or another party.

But TACK's developers also note that there is no reason that TACKs must only be retrieved "live" by the browser. Search engines could index well-known TACKs and browser-makers could pre-load lists of them into their applications. The TACK team has posted example TACK code for Apache and OpenSSL, plus a Python tool for making TACK requests.

Google, pins, and the future

Google submitted its own key-pinning proposal to the IETF, based on an evolution of its original feature in Chrome. The Google proposal is similar in many ways to TACK. For starters, unlike the built-in pinning currently found in Chrome, it allows each client application to check and cache its own pins rather than depend on a vendor-supplied list. It also pins individual site keys rather than CA keys, so it is independent of the CA chain-of-trust.

Google's pin format includes a max-age field, which takes the place both of TACK's expiration date and its maximum cache-lifespan criteria. Google's proposal does not track generations, however. To recover from a lost or stolen pin-signing key, it instead mandates that server administrators keep a "Backup Pin" — a second, un-deployed signing key that the administrators must store offline. The key fingerprint of the Backup Pin is published by the server, though, so that clients will recognize it if it needs to be deployed. Presumably when the Backup Pin is deployed, the administrators will then need to create a new, backup backup Pin.

There are other details that differ between the proposals (such as what signature algorithms are required), but the most fundamental difference is that Google's pinning proposal is an extension to HTTP: servers send their pinnable key signatures in a new HTTP header, rather than as part of the TLS handshake. TACK's proponents argue that because the CA weakness is fundamentally a TLS problem, it should be fixed in TLS itself, and that building an HTTP-based solution leaves other important protocols (e.g., IMAP and POP3) unprotected. HTTP proponents argue that an HTTP solution is easier to deploy due to the difficulty of setting up a TLS stack, and that HTTP protects the most attack targets.

As of today, TACK is being discussed by the IETF's TLS Working Group. It is a new enough proposal that it is likely to see revisions before it advances any further in the IETF standards process. Google's key pinning proposal was accepted as an Internet-Draft by the Web Security Working Group in December. Whichever makes it to broad browser and server acceptance first, it is fair to say that users will start hearing more about "pinning" in one form or another — but they still should not expect the CA system to disappear any time soon.