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."
Moxie Marlinspike (Score:4, Funny)
Sounds like a Batman villain.
Re:Moxie Marlinspike (Score:5, Funny)
Re: (Score:1)
Re: (Score:2)
Laugh while you can, fools! Shadowy government operatives in several key nations have leaked rumblings about the Final Ubuntu Codename, the ultimate mark of the End Times, the Last Word and Testament of the unholy Mark (Shuttleworth) of the Beast upon the blissfully ignorant army of Well Meaning Open Source Evangelists... and its name shall be the Ultimate Tyranny, the Final Cataclysm, the undeniable prelude to the Opening of the Heavens.
All will bow before the radiant glow of Zionist Zebra.
You have no chan
TACK (Score:2)
Re:TACK (Score:4, Funny)
It's a sailing joke [thoughtcrime.org].
Re: (Score:3)
Re: (Score:2)
posting AC so I don't undo mods
I used a small spike on my "sailing knife" for decades in aid of splicing laid line. No longer have it, nor my fids. It somehow seems odd that somebody wouldn't recognize the term; I guess folks don't read or get out as much as they used to.
We all know what it means, it's just that it's a fucking stupid name for anyone, and especially for anyone who wants to be taken seriously as a "security expert".
If he was a stand up comic, fair enough, it would just be a fucking stupid name, but for a professional it's beyond stupid and into retarded territory.
There has to be a better way (Score:4, Interesting)
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.
Re: (Score:3, Interesting)
TACK isn't really about replacing CAs, that's more the goal of Moxie's other project, Convergence. To quote Moxie from the IETF TLS list: "While I see a project like Convergence as an attempt to provide increased 'trust agility,' I see TACK as an attempt to reduce the surface for which third party trust is even required. The two types of projects are not incompatible, and in fact the latter simply reduces the amount of work the former needs to do."
Re:There has to be a better way (Score:4, Insightful)
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.
You're still bringing in an absolute arbiter, just hiding it a little. Or to clarify, without an absolute arbiter, there are no certificates marked as frauds, just those marked as unpopular.
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. This offers nothing as it will simply lead to distributed manipulation fo trust attacks, although in a best-case scenario you can build a model that forces the botnets to be civil a significant majority of the time and only support hostile certificates irregularly.
A Band-Aid On A Gaping Wound (Score:3)
"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 multip
Crowdsourcing will not help (Score:5, Insightful)
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." [sitetruth.com] for the details of who does that dirty work.
The trouble with crowdsourcing is that crowds can be outsourced.
Re: (Score:3)
Also see the MPAA endorsed poisoning of bittorrent swarms. 'secure by popular opinion' is a risky proposition, and IMHO TACK+CA is the best path and not TACK+Convergence.
Re: (Score:2)
"he trouble with "web of trust" schemes like that is fake "people", i.e. dummy accounts."
No. See my other post above. The REAL problem with the "web of trust" is that the parties you are supposed to be trusting are untrustworthy. Third parties spoofing certs is a drop in the bucket in comparison.
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.
What does this buy you? (Score:2)
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
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.
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: (Score:2)
The CA signing is still required to verify a) that the host hasn't been breached
So for one, I don't see why TACK private key would be kept online, it doesn't have to be used continuously. Secondly, if a server is compromised enough that the private keys of any sort are compromised, *nothing* protects you. They don't need a key to sign a 'counterfeit' key, they can just grab the official, blessed server private key. First-time visitor case is better with CA, repeat-visitor case is far less secure than is possible. TACK helps the repeat visitor case to be resilient to compromised CA,
PKI failure, back to self-signed certs (Score:2, Funny)
This sounds like going back to a variation on self-signed certificates. The server signs it's certificate with it's own local-CA private key, plus has it signed by someone like Verisign. The first time you hit the server, you check the Verisign signature as well as the self-signature. If both check out, you remember the self-signature and proceed to ignore Verisign from there on out. If you see a certificate purporting to be from the site but not signed with the local-CA key you remember it using before, yo
Re:PKI failure, back to self-signed certs (Score:5, Insightful)
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.
Better yet, self-signed certs + DNSSEC (Score:2)
How about we just admit that the current PKI is fatally compromised
I'd prefer a model where each domain acts as its own CA, with the signing certificate stored in DNS and verified through DNSSEC. It wouldn't be any worse than the existing domain-validated certs that many CAs offer.
Re: (Score:2)
You mean you want to implement the DANE proposal ?
Well, you just have to wait a bit till NSSEC is widely deployed and the proposal ratified. But the protocols are already on paper.
https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ [ietf.org]
Re: (Score:3)
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 prov
Internet Proposes New Name for Moxie Marlinspike (Score:1)
Something like Dave, maybe.
Re: (Score:2)
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
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.
"TACK key" (Score:2)
TACK key
TACK key
TACK keys
TACK key
TACK key
And this has been today's example of why the Geneva conventions should have included a section forbidding free software developers and researchers from ever naming anything.
CertificatePatrol (Score:2)
Trust is the weakest link in online security (Score:1)
Re: (Score:1)
Crikeys (Score:2)
Then come back and tell us why IT people don't get the respect they deserve.
Any verification will be done with software (Score:2)
Therefore, you already trust the software that will be doing the verification. If you already trust the software, then its one step further to have the software provider administer the certificates. All certificates should be signed by the software provider as the trusted authority. Your browser or library comes with baked in certs
and only those certs can be used to update to different certs or to authenticate certs.
The browsers et all are already gatekeepers of your security. Lets just make it offic