Two independent researchers are proposing an extension for TLS to provide greater trust in certificate authorities, which have become a weak link in the entire public key infrastructure after some big breaches involving fraudulent SSL certificates.
TACK, short for Trust Assertions for Certificate Keys, is a dynamically activated public key framework that enables a TLS server to assert the authenticity of its public key. According to an IETF draft submitted by researchers Moxie Marlinspike and Trevor Perrin, a TACK key is used to sign the public key from the TLS server’s certificate. Clients can “pin” a hostname to the TACK key, based on a user’s visitation habits, without requiring sites modify their existing certificate chains or limiting a site’s ability to deploy or change certificate chains at any time. If the user later encounters a fraudulent certificate on a “pinned” site, the browser will reject the session and send a warning to the user.
“Since TACK pins are based on TACK keys (instead of CA keys), trust in CAs is not required. Additionally, the TACK key may be used to revoke previous TACK signatures (or even itself) in order to handle the compromise of TLS or TACK private keys,” according to the draft.
“TACK pins are easily shared between clients,” the two engineers later added. “For example, a TACK client may scan the Internet to discover TACK pins, then publish these pins for other clients to rely upon.”
With the average browser now trusting more than 650 certificate authorities, cybercriminals have increasingly targeted SSL certificates — especially to launch man-in-the-middle attacks.
Last year a hacker broke into the servers of CA reseller Comodo to fraudulently obtain certificates for mail providers Gmail, Hotmail and Yahoo Mail. Then Dutch certificate authority DigiNotar suffered a breach that led it to issue a fake certificate for google.com and all of its subdomains, resulting in eavesdropping on some 300,000 Gmail users.
The key to TACK is a seemingly simple certificate pinning protocol added to Transport Layer Security. “A TACK client maintains a store of pins for verifying TLS connections. Pins associate a hostname and a TACK key. When a client sees a new hostname and TACK key combination, an inactive pin is created. Every subsequent time the client sees the same pin, the pin is ‘activated’ for a period equal to the timespan between the first time the pin was seen and the most recent time, up to a maximum period of 30 days,” the cryptographers wrote.
“Pin activation prevents an attacker with short-lived control of the hostname from activating long-lived pins. It also makes it safer for sites to experiment with TACKs, as a new TACK can be discarded without causing long-lived problems. The 30 day limit guarantees that a worst-case pin can be recovered from in reasonable time.”
Marlinspike gained attention (and fans) last year when he unveiled Convergence, which provides an alternative approach to vetting SSL certificates. It uses “notary servers” to handle trust decisions based on where the same certificate is located.
TACK has been compared to the certificate-pinning mechanism Google has built into its Chrome browser. (The company’s engineers also have drafted an IETF proposal on public key pinning.) However, those familiar with both say Google’s protocol works with a static list of certifiate authorities; whereas, TACK is designed to be more dynamic.
