eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Two researchers have proposed an extension to TLS, or transport layer security, as a solution to some of the security challenges facing the Secure Sockets Layer certificate ecosystem.
Their proposal comes after a troublesome year for certificate authorities (CAs) during which a number of high-profile CA security breaches shook the IT industrys confidence in SSL certificates and raised questions about whether it was time to develop some new certification process.
In response to the situation, researchers Moxie Marlinspike and Trevor Perrin have outlined a proposal for what they call TACK, or Trust Assertions for Certificate Keys. In a paper detailing their approach, the researchers explained their approach can help address the problem of attackers spoofing SSL certificates by enabling a site to sign its TLS server’s public keys with a TACK key.
“Traditionally, a TLS client verifies a TLS server’s public key using a certificate chain issued by some public CA,” they wrote. “‘Pinning’ is a way for clients to obtain increased certainty in server public keys. Clients that employ pinning check for some constant pinned element of the TLS connection when contacting a particular TLS host.”
“Unfortunately, a number of problems arise when attempting to pin certificate chains: The TLS servers at a given hostname may have different certificate chains simultaneously deployed and may change their chains at any time, the ‘more constant’ elements of a chain (the CAs) may not be trustworthy, and the client may be oblivious to key compromise events which render the pinned data untrustworthy,” they explained.
Signing TLS server public keys with TACK keys allows clients to pin a hostname to the TACK key without requiring sites to modify their existing certificate chains or limiting the site’s ability to deploy different certificate chains on different servers or change certificate chains at any time.
“Inside the TACK is a public key and signature,” the researchers wrote. “Once a client has seen the same (hostname, TACK public key) pair multiple times, the client will ‘activate’ a pin between the hostname and TACK key for a period equal to the length of time the pair has been observed for. This ‘pin activation’ process limits the impact of bad pins resulting from transient network attacks or operator error.”
If the user comes across a fraudulent certificate on a pinned site, their browser will reject the session and alert the user, they explained.
Their work follows a handful of incidents in the past year that put a spotlight on CA security. In March 2011, for example, an attacker hit a Comodo affiliate registration authority and stole the username and password for a trusted Comodo partner. Using those credentials, the attacker was able to request nine digital certificates across seven domains, including: login.yahoo.com, mail.google.com, login.skype.com and addons.mozilla.org. According to Comodo, the situation was discovered within hours of the attack and all nine certificates were revoked.
Five months later, certificate authority DigiNotar admitted it had been hacked earlier in the year, and Google reported an attacker used a fraudulent certificate from DigiNotar in man-in-the-middle attacks against Google users. Reports of the compromise affecting DigiNotar prompted browser vendors to revoke hundreds of bogus SSL certificates issued by the company. The situation ultimately forced DigiNotar to declare bankruptcy. Then, in November, telecommunications company KPN temporarily stopped issuing certificates after concerns were raised about a possible breach.
Since TACK pins are based on TACK keys, trust in the CA is not required. The TACK key may also be used to revoke previous TACK signatures in order to handle the compromise of TLS or TACK private keys, the researchers wrote.
“We’re hoping this is a fairly uncontroversial proposal,” Marlinspike said in an email to eWEEK. “The next step is to start having conversations with browser vendors about opportunities for integration.”