A pair of security researchers have proposed an extension to the Transport Layer Security (TLS) protocol that would allow browsers to detect and block fraudulently-issued SSL certificates.
Called TACK, which is short for Trust Assertions for Certificate Keys, the extension was developed by security researchers Trevor Perrin and Moxie Marlinspike and was submitted for consideration to the Internet Engineering Task Force (IETF), the body in charge of TLS, on Wednesday.
TACK tries to resolve the trust-related problems with the public key infrastructure that were highlighted by last year’s security breaches at certificate authorities (CAs) Comodo and Diginotar.
Both of those breaches resulted in SSL certificates for high profile domains like google.com, hotmail.com or mail.yahoo.com, being issued fraudulently. In Diginotar’s case, the certificates were even employed in active attacks against Google users in Iran.
At the moment, Web browsers trust over 600 organizations from around the world to issue SSL certificates. These organizations are known as certificate authorities and every one of them can technically issue a valid certificate for any domain on the Internet.
Several proposals to improve the current CA-based system have been put forward by Internet and security experts in the past 12 months, but there’s no consensus regarding which one offers the best solution.
In November 2011, security engineers from Google proposed an HTTP extension called “public key pinning” that would allow websites to effectively tell browsers via an HTTP header which certificate authorities should be trusted to issue SSL certificates for their domain names.
The browsers would then remember (pin) this information and refuse to establish the connection if they receive a certificate signed by a different CA in the future. A more static implementation of this system already exists in Google Chrome for particular domain names, including Google’s.
TACK is based on the same public key pinning concept, but instead of pinning CA public keys to particular domain names, it pins public keys generated by the domain owners themselves.
With TACK, the domain owner can generate a pair of private and public keys called TACK keys. The private key is used to sign the server’s TLS public key, which is currently used by browsers to validate SSL certificates. The TACK public key is then shared with connecting browsers and is used to validate the TACK-signed TLS public key.
The browsers can pin a TACK public key to a domain name if they receive it from the server on several separate occasions. If an attacker attempts to use a rogue SSL certificate to spoof a secure connection to a domain name that already has a TACK key pinned to it, the browser will not authorize it because the TACK validation will fail.
This creates a secondary protection layer, because in addition to a fraudulently-obtained, CA-signed, SSL certificate, an attacker would also need the domain owner’s private TACK key in order to pull off a successful attack.
TACK is designed to be backward-compatible with both clients and servers that lack support for it. In such situations, the HTTPS connection gets negotiated according to the current CA-based validation system.
This aspect is particularly important given the slow adoption of new TLS versions by Web server owners. According to Trustworthy Internet Movement’s SSL Pulse project, fewer than two percent of the Internet’s top 200,000 HTTPS-enabled websites support TLS 1.1 or 1.2, the latest versions of the protocol.
The vast majority of websites still support SSL 3.0, the precursor of TLS, and TLS version 1.0, which was designed in 1999. Over 30 percent of them still support SSL 2.0, the first publicly available and most insecure version of the protocol.
Under these conditions, it’s hard to imagine TACK becoming widely implemented anytime soon, even if the extension ends up receiving approval from the IETF.