×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Moxie Marlinspike Proposes New TACK Extension To TLS For Key Pinning

samzenpus posted about 2 years ago | from the protect-ya-neck dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

55 comments

Moxie Marlinspike (4, Funny)

Anonymous Coward | about 2 years ago | (#40100245)

Sounds like a Batman villain.

Re:Moxie Marlinspike (4, Funny)

Ogi_UnixNut (916982) | about 2 years ago | (#40100429)

I thought it sounded like a new naming scheme for Ubuntu :/

Re:Moxie Marlinspike (1)

Anonymous Coward | about 2 years ago | (#40100895)

Same thing, if you ask me.

Re:Moxie Marlinspike (1)

philip.paradis (2580427) | about 2 years ago | (#40106253)

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 chance to survive make your time.

Re:Moxie Marlinspike (0)

Anonymous Coward | about 2 years ago | (#40101285)

Penn Jillette would fucking LOVE this name.

TACK (2)

operagost (62405) | about 2 years ago | (#40100279)

Sounds tacky.

Re:TACK (0)

Anonymous Coward | about 2 years ago | (#40100297)

That's the point. It would successfully defeat Iran's interception with stolen keys or even the device Verisign sells to law enforcement for SSL interception.

Re:TACK (3, Funny)

Hatta (162192) | about 2 years ago | (#40100397)

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

Re:TACK (0)

Anonymous Coward | about 2 years ago | (#40100583)

Or just a synonym for 'pin'?

Re:TACK (2)

Jawnn (445279) | about 2 years ago | (#40101699)

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.

Re:TACK (0)

Anonymous Coward | about a year ago | (#40104593)

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.

Re:TACK (1)

tehcyder (746570) | about 2 years ago | (#40107551)

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.

Re:TACK (0)

Anonymous Coward | about 2 years ago | (#40107689)

Wow, someone should tell renowned computer security expert Moxie Marlinspike that with a name like Moxie Marlinspike he'll never been be taken seriously as a security expert. I'm sure he'll be very grateful for the advice and subsequent riches that will be showered upon him!

What's that? I should ignore morons on the internet? But then there would be no internet.

Re:TACK (0)

Anonymous Coward | about 2 years ago | (#40101731)

Hm. Moxie's bio is outdated; he's actually employed by Twitter for quite some time now.

Finally! (0)

Anonymous Coward | about 2 years ago | (#40100293)

Decentralized TLS authentication is very welcome.
Convergence is great but it won't help my grandmother not get scammed.

Thanks Moxie

There has to be a better way (3, Interesting)

Anon-Admin (443764) | about 2 years ago | (#40100311)

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:There has to be a better way (3, Interesting)

Anonymous Coward | about 2 years ago | (#40100351)

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 (4, Insightful)

Anonymous Coward | about 2 years ago | (#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.

A Band-Aid On A Gaping Wound (2)

Jane Q. Public (1010737) | about 2 years ago | (#40102237)

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

Re:There has to be a better way (0)

Anonymous Coward | about 2 years ago | (#40100515)

Your message is trusted.

Crowdsourcing will not help (4, Insightful)

Animats (122034) | about 2 years ago | (#40100747)

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:Crowdsourcing will not help (2)

Junta (36770) | about 2 years ago | (#40100811)

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:Crowdsourcing will not help (1)

Jane Q. Public (1010737) | about 2 years ago | (#40102275)

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

Re:There has to be a better way (0)

Anonymous Coward | about a year ago | (#40105093)

That pretty much sums up what PGP is.

Re:There has to be a better way (0)

Anonymous Coward | about 2 years ago | (#40105667)

There is an issue with P2P certificate authorities, they could be abused as well, just think of the botnet's that have millions of compromised computers. What would prevent them from trusting a certificate of a site that is malicious. Also you do forget many users would just click trust, because they wouldn't know much about how malicious the site might be.

Slashdot Deletes comments they do not like (-1)

Anonymous Coward | about 2 years ago | (#40100321)

Isn't that nice. You people just delete things that you do not like to see.

You people would make Pravda proud!

Feh

Re:Slashdot Deletes comments they do not like (0)

Anonymous Coward | about 2 years ago | (#40100523)

Got proof?

Re:Slashdot Deletes comments they do not like (0)

Anonymous Coward | about 2 years ago | (#40107075)

He did, but it was deleted!

This will help nothing (0)

Anonymous Coward | about 2 years ago | (#40100325)

It looks like this will require users to take extra steps or know something at all about encryption and https.

For this reason, it will not work - especially for the most vulnerable users who need the most help.

Not the way I read it... (3, Informative)

Junta (36770) | about 2 years ago | (#40100569)

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? (1)

igb (28052) | about 2 years ago | (#40100337)

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?

Re:What does this buy you? (4, Informative)

Anonymous Coward | about 2 years ago | (#40100395)

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

Re:What does this buy you? (0)

Anonymous Coward | about 2 years ago | (#40100897)

Plus on your first visit how do you know whether the certificate is trustworthy?

Key continuity management (3, Informative)

tepples (727027) | about 2 years ago | (#40100633)

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.

I need to read up on security... (-1)

Anonymous Coward | about 2 years ago | (#40100359)

Not much point to post this, but after reading the title, am I the only one who thought:

"Who proposes what to where for what now?"

Doesn't replace CAs by any means (3, Informative)

Baloroth (2370816) | about 2 years ago | (#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.

Re:Doesn't replace CAs by any means (0)

Anonymous Coward | about 2 years ago | (#40100425)

I think the TACK key is an "offline" signing key, meaning that it shouldn't be kept on the TLS server, and wouldn't be lost in the case of a breach.

My guess is that they'll probably migrate Convergence towards verifying TACKs rather than certificates. Or, at least being TACK aware. Validating the first connection you ever make to a website is an easier problem to solve than validating every connection you ever make to a website.

Re:Doesn't replace CAs by any means (1)

Junta (36770) | about 2 years ago | (#40100631)

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, which is a very real risk. No third-party trust system will work as well as something like TACK at that use case.

PKI failure, back to self-signed certs (1, Funny)

Todd Knarr (15451) | about 2 years ago | (#40100405)

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.

Re:PKI failure, back to self-signed certs (0)

Anonymous Coward | about 2 years ago | (#40100501)

[T]he current PKI [...] assumes CAs will act contrary to their own self-interest by turning down customers and their money.

Not quite. If a PKI becomes known for signing bad certs, no one will trust it, so their *long term* self interest is to maintain sufficient standards to remain trusted. It does require the PKI to act against their *short term* self interest, which may still be asking too much.

The binary nature of trust exacerbates the problem, I think - either the CA is in my browser's trusted list or it isn't; it takes a lot to get it kicked, so it's very long term. If it was more granual, then people would be willing to pay more for certs that are signed by a better-trusted CA... but it certainly increases complication and whatnot.

Re:PKI failure, back to self-signed certs (4, Insightful)

DragonWriter (970822) | about 2 years ago | (#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.

Better yet, self-signed certs + DNSSEC (1)

tepples (727027) | about 2 years ago | (#40100669)

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:PKI failure, back to self-signed certs (2)

Junta (36770) | about 2 years ago | (#40100767)

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.

Internet Proposes New Name for Moxie Marlinspike (1)

Anonymous Coward | about 2 years ago | (#40100411)

Something like Dave, maybe.

A move to a decentralized scheme would be great. (0)

Anonymous Coward | about 2 years ago | (#40100427)

It's pretty clear that the large CAs are more interesting in leveraging their status to make money than actually proving a secure service.. Investing more in security theater than actual security practice.

At some point you must reconcile that with a commercial company, the bottom line is more important than real security. I'd welcome any opportunity to eject rent seekers for something that works better.

Re:A move to a decentralized scheme would be great (1)

CanHasDIY (1672858) | about 2 years ago | (#40100475)

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 (3, Informative)

rudy_wayne (414635) | about 2 years ago | (#40100805)

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" (1)

pushing-robot (1037830) | about 2 years ago | (#40100665)

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 (1)

tomtomtom (580791) | about 2 years ago | (#40100909)

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.

Moxie is a JOKE. (0)

Anonymous Coward | about a year ago | (#40104939)

I heard this guy (Moxie) in RSA 2012. I am not sure first of all why anyone would call him a researcher. His arguments are baseless and it seemed like any time someone asked him a question during RSA 2012, he would ridicule the guy rather than answering it.
People like these dilute the word "research".

Crikeys (1)

Ol Olsoc (1175323) | about 2 years ago | (#40106231)

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.

Any verification will be done with software (1)

Marrow (195242) | about 2 years ago | (#40109773)

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

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...