Moxie Marlinspike Proposes New TACK Extension To TLS For Key Pinning 55
Trailrunner7 writes "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."
Doesn't replace CAs by any means (Score:4, Informative)
A CA signed certificate is still required (well, unless you want a self-signed warning on every browser). This system just allows you to verify for repeated visitors that a new, un-TACK-signed certificate isn't being used. The CA signing is still required to verify a) that the host hasn't been breached (in which case the TACK key would be lost, since as I understand it they retain the private key) and b) that first-time visitors can get a moderately-trustworthy (or at least the same as currently exists) session. This system would require that both the host and the CA are compromised. It's somewhat similar to the Convergence system that was proposed before, only instead of having cloud-sourced verification of the certificate, you have the host verify (based on past experience) that the certificate is valid. By itself, it isn't very secure, but in addition to the present system it adds a great deal of security.
Re:What does this buy you? (Score:4, Informative)
Because certificates change under completely normal circumstances, which is partially why the existing Chrome pins are to CA certificates rather than site certificates. Moxie responded to a similar question here: http://www.ietf.org/mail-archive/web/tls/current/msg08821.html
Not the way I read it... (Score:4, Informative)
The way I read it, it is something closer to the way ssh known_hosts work (though with more flexibility for key changes). Not intended to wholly replace third-party attestation, but supplement it.
On first visit, browser takes the CA's word for it for lack of prior TACK knowledge. Then it also gets the TACK information, subsequent trips must pass *both* CA and TACK checks. If a trusted CA starts going wild, most traffic will not be able to be MITM because they haven't simultaneously defeated TACK. There is an exposure for first-time visits in a world with a compromised CA, but it does protect against the most common case.
Key continuity management (Score:4, Informative)
I'm not clear what signing a key with another, self-signed, key achieves.
It's called "key continuity management". (Google that phrase.) You may not be sure that you are communicating with a specific real-world entity, but at least you know you are communicating with the same entity with which you had communicated before.
Re:A move to a decentralized scheme would be great (Score:4, Informative)
It's pretty clear that the large CAs are more interesting in leveraging their status to make money than actually proving a secure service..
At some point you must reconcile that with a commercial company, the bottom line is more important than everything else.
FTFY
Which is why the whole Certificate process is fundamentally broken.
1 - There are too many CA's
One one hand, you don't want a few companies to have a monopoly, but too many CA's greatly increases the chances that someone will be compromised. Several of the recent fraudulent certificates came from smaller "resellers".
2. An automatic conflict of interest.
The number one priority of any business is to make money. And that's understandable -- if you don't make money you go out of business. In order for certificates to work as intended, CA's would have to turn away customers (and money). But because fraudulent certificates are not as noticeable or as well publicized as things like defective household appliances, there is little incentive for CA's to reject untrustworthy customers.