Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Security IT

Moxie Marlinspike Proposes New TACK Extension To TLS For Key Pinning 55

Posted by samzenpus
from the protect-ya-neck dept.
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."
This discussion has been archived. No new comments can be posted.

Moxie Marlinspike Proposes New TACK Extension To TLS For Key Pinning

Comments Filter:
  • by Anonymous Coward on Thursday May 24, 2012 @10:42AM (#40100245)

    Sounds like a Batman villain.

    • by Ogi_UnixNut (916982) on Thursday May 24, 2012 @11:04AM (#40100429) Homepage
      I thought it sounded like a new naming scheme for Ubuntu :/
      • by Anonymous Coward
        Same thing, if you ask me.
      • 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

  • by operagost (62405)
    Sounds tacky.
    • Re:TACK (Score:4, Funny)

      by Hatta (162192) on Thursday May 24, 2012 @10:59AM (#40100397) Journal

      It's a sailing joke [thoughtcrime.org].

      • by Jawnn (445279)
        Not a joke, really. A marlinspike is a sailor's tool. Most of it's uses are antiquated, but it's still handy for certain jobs, like prying open a jammed knot.
  • by Anon-Admin (443764) on Thursday May 24, 2012 @10:50AM (#40100311) Homepage Journal

    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)

      by Anonymous Coward

      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."

    • by Anonymous Coward on Thursday May 24, 2012 @11:11AM (#40100489)

      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.

      • "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

    • by Animats (122034) on Thursday May 24, 2012 @11:43AM (#40100747) Homepage

      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.

      • by Junta (36770)

        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.

      • "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.

  • I'm not clear what signing a key with another, self-signed, key achieves. Why not just cache certificates presented by servers, and complain if a server you have previously contacted presents a fresh certificate for reasons other than expiration?
  • by Baloroth (2370816) on Thursday May 24, 2012 @10:56AM (#40100365)

    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.

    • by Junta (36770)

      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,

  • 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

    • by DragonWriter (970822) on Thursday May 24, 2012 @11:23AM (#40100581)

      This sounds like going back to a variation on self-signed certificates.

      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.

      If you want a PKI based on signing certificates by CAs, the CAs need to be entities whose primary income does not derive from signing certificates.

      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.

    • 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.

    • by Junta (36770)

      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

  • Something like Dave, maybe.

  • 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 [mozilla.org] offers 80 percent of what this extension will do without the requirement for server participation. Given how many SSL sites don't even support the newest SSL/TLS protocol, it would seem to be more valuable. I get that adding offline signing keys which are supposed to be invariant helps but I can't see most sites going to the hassle to be honest.
  • Or any security protocol for that matter.
  • Get a normal person in here and try to parse that article.

    Then come back and tell us why IT people don't get the respect they deserve.

  • 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

Mediocrity finds safety in standardization. -- Frederick Crane

Working...