Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security IT

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."
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 @11:42AM (#40100245)

    Sounds like a Batman villain.

  • Re:TACK (Score:4, Funny)

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

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

  • by Todd Knarr ( 15451 ) on Thursday May 24, 2012 @12:00PM (#40100405) Homepage

    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, you throw up an error. This reminds me of a system I suggested before: let users tie SSL certificates to a list of servers and associate the list with a human-readable name (an entity). Then let the user activate a secure mode to visit a particular entity, at which point the browser would reject content from any server not in the remembered list or not presenting a remembered certificate. The two systems have the same vulnerability: the browser can be fooled into accepting a false certificate during the first visit, and if it is the user'll never see any indication of a problem after that. TACK though has the advantage of potentially requiring the browser to remember only one TACK key instead of multiple certificates.

    How about we just admit that the current PKI is fatally compromised: it assumes CAs will act contrary to their own self-interest by turning down customers and their money. 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.

  • by Ogi_UnixNut ( 916982 ) on Thursday May 24, 2012 @12:04PM (#40100429) Homepage
    I thought it sounded like a new naming scheme for Ubuntu :/

Old programmers never die, they just hit account block limit.

Working...