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.
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.
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
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
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
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.
to post comments)