Slashdot Mirror
Moxie Marlinspike Proposes New TACK Extension To TLS For Key Pinning
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."
Sounds like a Batman villain.
Sounds tacky.
Gamingmuseum.com: Give your 3D accelerator a rest.
It seems to me that you could do a p2p certificate authority where a certificates trust is based on the number of people who trust the cert as well as a past history of your trusts.
So, if historically you trust certs that are frauds then the trust in you is reduced and all certs you trusted are reduced.
If the opposite is true than the trust in you is higher as is the trust in the certs you have trusted.
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.
"None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
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
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.
XML is like violence. If it doesn't solve the problem, use more.
Its not. Its a verification scheme orthogonal to certificate chains which can be used either alongside traditional certificate chain verification or without traditional certificate chain verification. It is compatible with self-signed certs, but equally compatible with CA-signed certs. Ideally, you'd use it with CA-signed certs, since CA-signed certs -- though they have known problems -- are better than nothing (unlike self-signed certs) on a first connection with no prior information, but after that TACK pins are useful to detect later CA-assisted shenanigans.
No, what you need is an effective mechanism to detect and revoke trust in nefarious CAs. If CAs aren't trusted, they are of no value to potential clients, and thus the stream of income from signing certificates dries up. The problem isn't that CAs derive income from signing certificates, the problem is that there is no effective accountability mechanism that imposes sufficient consequences to make it so that improperly signing certificates reduces the marketability of that CA's signing services.
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.
It seems to me that you could do a p2p certificate authority where a certificates trust is based on the number of people who trust the cert as well as a past history of your trusts.
As someone else pointed out, that's Moxie's other project, Convergence. The trouble with "web of trust" schemes like that is fake "people", i.e. dummy accounts. Dummy account generators have trashed Craigslist, turned Hotmail into a reply service for spammers, garbaged Gmail, filled Google+ with fake accounts, and created vast numbers of bogus Yelp reviews. See my paper "Social is bad for search, and search is bad for social." for the details of who does that dirty work.
The trouble with crowdsourcing is that crowds can be outsourced.
It's an acknowledgement that no PKI infrastructure can offer a better assurance of continuity of trust than something along the lines of self-signed certificate. Establishing the trust in the first place is where PKI strategies are needed. In this scenario, TACK does nothing for initial connection, therefore PKI is used for that to bootstrap the TACK trust relationship. From then on, TACK protects against future PKI compromises. It's better than self-signed certificates and ssh host keys in that it provides facilities for administrators to manage expiry, revocation, and changes whereas usually changing the private key is going to induce headache.
Note also that you shouldn't "gnore Verisign from there on out". Both TACK and CA checks should pass once you can reasonably check both. In that way, a CA compromise is mitigated by TACK. Conversely, if your first visit was done when a CA was compromised, you'd end up with a malicious TACK setup. A subsequent visit having no cert verifiable by CA but passing TACK should still be rejected so that first-time MITM attacks can be mitigated later.
XML is like violence. If it doesn't solve the problem, use more.
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.
"Without an arbiter (or arbiting class), all you have are records of who trusted certifications that other people trusted and who trusted certifications that few others trusted."
The real problem here is that the whole "trust" model of CAs is broken, and has been from the beginning.
It does little good to verify certificates, as this scheme proposes, if the majority of the real security problem is with the CAs themselves, or with improper end-user implementation of certificates.
In a study done a few years ago, EFF found that among other things, there were too many CAs, and many of them were not following the rules. For a few examples: (A) some CAs were improperly selling multiple certificates for the same domain, (B) other CAs were (even worse!) selling the same certificate to multiple domains, and (C) as much as 80% of sites had their certificates installed improperly. In many cases the certificates were installed on a subdomain (such as www.) when it should have been on the main domain name, or vice versa.
Bolstering the "trust" of the certificates themselves does damned little good if the "authorities" that validating them are not following the rules, or people are not using the certificates properly in the first place.
All in all, this proposal would do little to solve anything, because it is proven that it is precisely the parties you are supposed to trust who are untrustworthy, when it comes to setting up or validating certificates.