Heartbleed should bleed X.509 to death

http://lorddoig.svbtle.com/heartbleed-should-bleed-x509-to-death

by lorddoig • 12 years ago

401 147 12 years ago

lorddoig.svbtle.com

From the perspective of a layperson with limited tech knowledge I really like the way you explain things!

wmf4• 12 years ago

A bug in a PGP implementation could have leaked your PGP private key. A bug in an SSH implementation could have leaked your SSH private key. CAs may be a flawed concept, but I don't think they have anything to do with Heartbleed.

lorddoig6• 12 years ago

Heartbleed knocked us down, the CA system is going to make it very difficult for us to stand up straight again - that's the point.

wmf4• 12 years ago

How much effort would it be to rebuild a web of trust after all the keys were simultaneously assumed compromised?

rst• 12 years ago

More importantly, they're certainly not the only threat presented by HeartBleed. While this guy drags his feet patching (because his certs still won't be really secure), his servers are likely leaking session cookies, usernames, and passwords by the bucketload.

valarauca12• 12 years ago

The problem I see with PGP is you'll end up with thousands if not millions of keys you need to keep on hand to decrypting everything. Not to mention the web of trust will be massive and navigating will likely start taking very large CPU power if its strictly peer to peer.

To avoid this most people will start just trusting larger companies; Google, Facebook, Apple, Mozilla. And only checking their keys, since they will trust that company's key. And these companies will handle signing new websites. Small websites won't care if you personally trust them, they'll only care if one of the 'big companies' trust them.

In the end we wind up exactly where we started. Large companies are implicitly trusted by everyone. Sure you may sign your key off to a few dev friends so you can access their test sites, which will make self signing easier. The cost will be mitigated, but in reality nothing will change. Even likely within a 3-4 Browser Generations we'll see non-Company trusted PGP keys get scrapped in all but the more free (as in beer) browsers.

lorddoig6• 12 years ago

I'm not sure this is the likely outcome. There are a lot of people out there savvy enough to not jump on the big company bandwagon - and they would be very vocal about why it's a bad idea too. I don't see your vision becoming a reality for as many as you expect, especially if PGP is brought into our lifestyles a bit more (e.g. email, chat) and the general population begin to understand it - it wouldn't be long before they understood enough to value building their own trust relationships.

valarauca12• 12 years ago

The problem is its not a personal savvy problem, its a mathematics problem. PGP will pick the shortest route. So if you trust google.com, and google.com trusts the site, bing-bang-boom your done.

The shortest route will always favor the person with the most keys and the most trust. Who invariably will figure out that he/she can make money getting more keys and more trust. Which lucky for us their are both a finite number of persons and a finite number of keys that will be signed by each key. We end up with a pyramid scheme.

Where the more trust and keys you have, the easier it'll be to get more trust and keys.

:.:.:

The problem is capitalism. In all honestly we'll likely see the PGP network end up in the hands of banks. You want secure access to you online account? Sign each other keys. Now the bank has a 5 million person strong trusted key. They'll sell that trust naturally. I trust most tech companies enough not to instantly monetize the PGP web, but some would.

Likely some tech company attempts to monetize it, they get yelled at. They stop. Another does, nothing changes so people accept it as the new norm. The arguments made it allows for faster page loads, easier access. Nobody says a word after a year.

zurn• 12 years ago

Large companies are implicitly trusted by everyone.

No. What little trust there is, it comes from people trusting them to be afraid for their own interests. But even then people generally acknowledge that the customer's interest might not always win here.

See eg. Linux refusal to use Intel's hardware RNG.

M2Ys4U2• 12 years ago

The difference between the CA system and the WoT system you're describing is that you can revoke your trust in, say, Google yet you'll still be able to validate certificates.

With the CA system as it is now, once a CA is trusted, it's effectively trusted FOREVER.

hendzen• 12 years ago

Not going to happen. The WoT is a usability nightmare for the 99.9% of nontechnical users that don't care about things like 'p2p' & 'decentralized'.

Do you really think Granny is going to be happy with the tablet she bought that can't connect to her online banking account out of the box? Have fun explaining to her that she needs to exchange keys with enough trusted intermediaries to have a valid trust path to her bank. I'm sure there plenty of key signing parties happening at the 'ol retirement home.

Or maybe you can explain to Granny why her money was stolen when a scammer managed to compromise one of her trusted keys and then created a compromised subgraph in the WoT leading to a fake certificate to her bank?

The WoT is a usability nightmare. Sure, the PKI isn't too great, but it's what we have, and it is currently more practical than any other solution out there. Security needs to be usable to be useful.

EDIT: for a good rebuttal to the OP, read this blog post by Mike Hearn which covers the issues I raised and more: https://medium.com/bitcoin-security-functionality/b64cf5912a...

lorddoig6• 12 years ago

So Granny huffs and puffs and calls me, trusts my key through the sexy new UI I talked about and is done with it.

I specifically said that PGP may not be the solution, but what we have now is just ridiculous if you really think about it. We have no choice but to trust 4 companies on precisely nothing but their word. Even if you mistrust their word - and I do - there is no alternative choice.

Security always boils down to trust in the end, and the status quo outsources it. It is the definition of stupid.

rmc• 12 years ago

You have a choice. Remove all CAs from your browser, and manually verify all the server signatures yourself.

nemothekid• 12 years ago

Calls who? Why should Granny trust you? What you described is no different, Granny is still outsourcing her trust to some 3rd party.

Or are we working under the assumption that every Granny has a grandson who is just as technically competent as you are? The fact of the matter is, PGP has just enough friction that if implemented correctly, will still lead to the vast majority of non-technical users simply signing up to some SaaS to handle it for them, and with that you end up in square one, where a handful of SaaS providers are the gatekeepers to everyones identity.

higherpurpose• 12 years ago

FYI, you should take a look at DNSChain:

https://github.com/okTurtles/dnschain

exelius3• 12 years ago

What happens when someone far away from you in the WoT is compromised by say, a botnet? Now you get compromised because a source you verified through your WoT loaded a malware-infested piece of software on your mobile device. So it's not necessarily any more secure.

The status quo outsources trust because that's what you do in an economy. We trust the government to secure the value of our money. We trust banks with storing that money, and we trust that the government again will make sure that they do.

If you want to see what happens when you DON'T outsource trust, look at how terrorist networks operate. They only deal with trusted associates who know each other personally, they only communicate through trusted couriers, and they live in fucking caves. It's not exactly conducive to a modern economy.

You have to outsource some level of trust. Otherwise you waste so much productivity on maintaining and verifying your trust network that you can't actually do anything worthwhile with it. I think the real question is "to whom?" and "for what purposes?" If you need something to be really secure, then you should probably do an in-person key exchange. For the majority of things people do you only need "mostly secure" because there are other protection measures in place in case the communication is fraudulent.

joosters• 12 years ago

And the proposed alternative is to instead trust just one entity, the PGP code? On top of that, it all falls flat if/when any of my trusted friends gets hacked, meaning I start trusting evil.example.com because their hacked key now tells me to?

lawl2• 12 years ago

WoT won't work, yes.

Sure, the PKI isn't too great, but its what we have, and it is currently more practical than any other solution out there. Security needs to be usable to be useful.

But I disagree with you here, there are better solutions that are just as easy to use:

- Some options: namecoin. If you own the domain you can easily sign stuff with the same key you use to own the domain

- Put stuff in DNS's TXT record once DNSSEC is rolled out. (Or create a new record)

Or take a look at TOR hidden services for example. You enter a onion domain. And you're there. Guaranteed. No messing around checking if there is a green lock or messing around with a WoT.

Note namecoin might not be there yet to be usable for 08/15 users. And most of them probably don't want the blockchain locally. But it's easy to imagine that you just have your ISP still provide you some sort of DNS service.

tlrobinson• 12 years ago

A "web of trust" is essentially an extension of the CA "tree of trust". Why can't we have both?

Apple can act as iPad users' first WoT node. If a user logs into Facebook they immediately add every Facebook friend to their web. etc, etc.

Just because WoTs are currently usability nightmares doesn't mean they have to be forever.

pixelcort2• 12 years ago

Isn't this what Keybase is kind of accomplishing?

bdamm• 12 years ago

Agreed. Somehow I feel we need to end up on reputation-based nodes of trust that do act as proxies into real-world trust. It must not be like PGP is now, but it does need to be distributed and based on local trust.

zanny4• 12 years ago

And you can easily have a web of distrust, in that if one of your more immediate trustees stops trusting a distant branch, you can at least prompt that something is wrong. That way you can avoid the whole "compromise one node and screw everyone over" problem as long as someone realizes the compromise before you trust it.

clarkm• 12 years ago

Check out SPKI / SDSI. It has a hybrid model similar to what you described, but unfortunately it never really gained adoption.

thefreeman3• 12 years ago

Even with just that single example the scaleability issue becomes apparent. I would never want to trust all of my Facebook friends with my computer security. And even less so for my friends' friends, etc.

And I certainly could be wrong in my understanding, but I believe all it takes is a single malicious (or pressured) actor to ruin that chain.

That seems scary to me.

bad_user• 12 years ago

In general I hate arguments that includes the grannies and grandpas of our world.

First of all because it makes the assumption that all of them are stupid somehow - or for the less adaptable ones that have problems with newer technology, it makes the assumption that the current status quo works. Do you think that granny from your example wouldn't click "Ignore" on a browser warning?

Second of all, if we really get down to an argument about elders, society and making the world a better place, the priority shouldn't be to keep the status quo because the elders wouldn't cope with change - because in that equation, today's children are more important, don't you think?

Have fun explaining to her that she needs to exchange keys with enough trusted intermediaries to have a valid trust path to her bank

That's false - she only needs to exchange keys with the bank directly.

dredmorbius• 12 years ago

I hate arguments that includes the grannies

The point isn't the slur on elderly users (though that often applies), but to think of the least-technical, large-base user likely to be trying to make use of your product.

In my experience, I've encountered technically challenged users of all stripes: the illiterate, PhDs, strangers on the Internet, immediate family and friends, children, the elderly, mentally or psychologically challenged, executives (but I repeat myself), entrepreneurs, the harried, etc. And, put quite bluntly, there's a hell of a lot of them.

Within the tech world we tend to be fairly insulated from the larger scope of this problem, and yet in my experience it's still ubiquitous.

The point of the example isn't to take affront, but to realize that for widely-deployed systems, base-level usability is crucially important.

poolpool• 12 years ago

Its not that they are stupid, many people have better things to do than spend a single second they don't have to staring at a monitor.

Different interests. Different focuses. No one will want to listen to you explain that its for the best, or the current issues with CAs (Also what a CA is). They just want to check their damn gmail.

pixelcort2• 12 years ago

In the past, key exchange was hard. Now it could be as simple as walking to your local Bank branch and scanning a QR code on a plaque with your smartphone (as mentioned in the article).

Online-only or remote businesses like social networks and airlines would face a tougher problem.

politician5• 12 years ago

Well, in the QR code and smartphone scenario, you also have to trust that the code in the smartphone all the way down to the hardware is trustworthy. Otherwise, you'll get attacked through the firmware or bugs in the OS or through custom sleeper electronics injected at the fab.

hadees• 12 years ago

What about if there was a hybrid solution where we all collectively issue certificates in some sort of p2p model. I know there are huge technical hurdles to that and you have to be careful of nefarious parties trying to inject bad certs but at least we would get rid of the monopoly.

im3w1l• 12 years ago

Or the bank (which she trusts) sends her a magic-code (which adds the banks public key as the only key to be used for their domain) for the tablet, along with the 2-step authentication device.

rubbsdecvik2• 12 years ago

PGP would be a problem for high load servers too.

"Why not use public-key encryption for everything?

At face value, it seems that the existence of public-key encryption algorithms obsoletes all our previous secret-key encryption algorithms. We could just use public key encryption for everything, avoiding all the added complexity of having to do key agreement for our symmetric algorithms. By far the most important reason for this is performance. Compared to our speedy stream ciphers (native or otherwise), public-key encryption mechanisms are extremely slow. A single 2048-bit RSA encryption takes 0.29 megacycles, decryption takes a whopping 11.12 megacycles. To put this into comparison, symmetric key algorithms work in order of magnitude 10 or so cycles per byte in either direction. In order to encrypt or decrypt 2048 bytes, that means approximately 20 kilocycles."

https://www.crypto101.io/

EDIT: I suck at copy-pasta

wmf4• 12 years ago

I think the author is proposing to replace CAs with PGP-like web of trust but keep the rest of SSL/TLS the same, so public key crypto would only be used to setup a session key.

rubbsdecvik2• 12 years ago

That's fair. I re-read the article and see your point. I would still agree with other comments here that a WoT would be difficult to implement in a user friendly way that wouldn't also be exploited.

astrodust2• 12 years ago

Can't this be solved with some kind of distributed, authenticated, pre-existing protocol? Something like...

DNS?

With the DNSsec extensions it should be possible to publish enough information to authenticate a given site against a certificate. If your DNS has been compromised you've got bigger problems than your SSL cert.

wmf4• 12 years ago

http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Nam...

josteink• 12 years ago

If your DNS is compromised SSL and x509 is currently what's protecting your users from a fraudulent site.

lawl2• 12 years ago

If your DNS is compromised SSL and x509 is currently what's protecting your users from a fraudulent site.

Uhm no? Because you can litterally just buy a new valid cert for it? As long as we're talking Domain Validated.

I doubt your average user will notice that there isn't a green bar anymore or that the certificate lacks ownership information.

astrodust2• 12 years ago

If DNSsec allows your domain's certificate to be signed vs. a more root authority (e.g. .com) then it would be a lot harder to introduce fraudulent DNS records.

sparkie• 12 years ago

DNSsec is still broken by hierarchical trust - implied by some "authority", rather than chosen by the user.

I think the solution needs to be something like Moxie's Convergence, which allows for users to decide who they trust, and revoke such trust at any time.

https://www.youtube.com/watch?v=8N4sb-SEpcg

It's a shame that Convergence is basically dead, although there's still some activity in Perspectives on which it was based. (http://perspectives-project.org/)

rakoo• 12 years ago

it should be possible to publish enough information to authenticate a given site against a certificate

You can, it's called DANE and is a future standard [0]. We're just waiting for DNSSEC to spread because without DNSSEC everything is unsecure.

[0] https://tools.ietf.org/html/rfc6698

notdonspaulding• 12 years ago

And fundamentally you have to trust that they who hold the Queens aren’t dishing out copies of your certificates.

In general, I'm a fan of analogy, but I'm having trouble following this whole queen/princess/baby thing. Putting that aside, I think you're claiming that CAs can present your certs to random clients?

This might be an indictment against the DNS system, which directs the clients to an IP address of its choosing, but if the client makes it to your server, your server chooses which cert to present to the client.

What we have done here is fitted our doors with some mega heavy duty locks, and given the master keys to a loyal little dog.

Again with the strained analogy. Who's the dog? What does the mega lock represent?

I think this belies a fundamental misunderstanding of what the CA is doing. The client asks your service to validate itself, your service does so by saying that Verisign/Thawte/etc. has previously signed the cert that your service sent to the client. The client does not have to automatically trust Verisign or Thawte or whomever you say signed it, and furthermore, if it decides that it does trust that party, the NSA is not able to use that to its advantage in any way as a result of Heartbleed.

As of today, that green padlock no longer means what it once did. And the reason for that is because of the business conditions of gatekeepers.

No, it doesn't mean what it did yesterday because of a bug in an implementation of OpenSSL. The protocol is still just as valid. The business conditions of the gatekeepers, while distasteful to you, doesn't invalidate the mechanisms by which that little green padlock gained its fame.

jessaustin2• 12 years ago

...if the client makes it to your server, your server chooses which cert to present to the client.

Ummm, that's kind of a big "if". The whole point of authentication is to resist an adversary who controls the network. We already know we can't rely on DNS (or any of the other 37 moving parts involved).

joshstrange2• 12 years ago

Not the OP but I think I might be able to help.

> I think you're claiming that CAs can present your certs to random clients? This might be an indictment against the DNS system, which directs the clients to an IP address of its choosing, but if the client makes it to your server, your server chooses which cert to present to the client.

Here I am fairly confident that he is talking about a situation in which a CA signs a key for your domain and gives it to someone else (NSA/GCHQ) and they preform a MITM attack on a user like this:

Client -> Fake key for yourdomain.com provided by MITM proxy server -> decrypt data then encrypt with real key for yourdomain.com -> Your Server

CA's have been compromised before [0] (and I'd be willing to bet there are quite a few more incidents that they have swept under the rug) and so there has been discussion on what happens when you can sign a certificate for any domain. I believe this is what the OP is referencing.

> Again with the strained analogy. Who's the dog? What does the mega lock represent?

I agree with you, this one is harder to understand. As I see it the mega lock = CA's private keys, dog = CA's. When he talks about the dog being tempted by a steak he is referencing the rumors that the NSA/GCHQ have back room agreements (steak) with CA's or have simply hacked the CA's and taken what they needed (for this I would say something like "the dog was asleep").

> No, it doesn't mean what it did yesterday because of a bug in an implementation of OpenSSL. The protocol is still just as valid. The business conditions of the gatekeepers, while distasteful to you, doesn't invalidate the mechanisms by which that little green padlock gained its fame.

This is less cut and dry than you suggest. The green padlock has always meant jack-shit when it comes to state actors (if you subscribe to the theory that they have either bought off one or more CA's or hacked them, which I do), what it did protect you from was your run-of-the-mill online criminal. It made it impossible for them to sniff your login credentials a la Firesheep[1] (Yes the padlock itself didn't do that, the PKI did but it gave people a simple way to check if the connection was secure and the website was who it said it was). What the heartbleed bug did was allow ANYONE to potentially steal your private key right off your server, opening the door to not only NSA/GCHQ but anyone with an internet connection (and the knowledge to exploit it).

The OP is suggesting that CA's should have revoked certificates to force people to fix their servers but they never would due to the backlash. CA's have the ability to revoke certificates that are compromised and we have to assume every certificate has been. I don't know what the right course should be but one that spring to mind iss giving everyone a deadline at which point all certificates will be revoked and refuse to re-issue a certificate to a url that is still vulnerable to heartbleed. YES, this is extremely and no it's neither simple nor easy but I think there are very good reasons for why it should be done. The thing is, at least IMO, that CA's really don't give a shit, like the OP suggests they care about one thing and one thing only: their investors. If they really did care about making the web a safer and more secure place then why aren't they sponsoring OpenSSL or working on their own open source SSL library?

[0] http://crypto.stackexchange.com/a/11765

[1] http://codebutler.com/firesheep/

throwaway2048• 12 years ago

with a properly done CSR (certificate signing request), a CA never has access to your private key, therefore cannot "give it to someone else"

strictfp• 12 years ago

WoT and CA systems are both problematic since they can be altered on the fly and thus 'hijacked'.

I wonder if we wouldn't be better of with something similar to what SSH does. Accept trust the first time and verify that the signature doesn't change on every subsequent connection attempt. This way one would be immune to hijacks.

It wouldn't solve first time verification, but how likely is a first time spoof? And for really sensitive communications you could use pre-shared keys. I could for instance get a hardware token from my bank containing their public key.

saintgimp2• 12 years ago

A couple of problems:

The average internet user has no idea who's trustworthy and who isn't. If they have to personally grant trust in order to get at some content they're looking for, they'll simply do it. This is the same behavior that causes people to execute boobs.exe attached to a random email that landed in their inbox.

In order for this to work, the average internet user must cede the trust decision-making process to some other entity who claims to be more qualified to do it, like say the company who makes their browser. There are four browser makers that account for probably 90+% of usage. Now you're right back to where you started with the current oligopoly system, except that with the new system there's a much larger attack surface for nefarious agents to use when trying to insert themselves into the trust chain because anyone at all could let them in.

Cynically, that's the problem with internet security protocols in general - they have to work not only for smart, self-interested people but also for stupid people who are actively self-harming. That's a really tough bar to meet.

exelius3• 12 years ago

The problem isn't any one cryptography scheme; the problem is trust. How do we build a trust framework that facilitates commerce on a wide scale while remaining truly secure? I don't think we can; so we give up a little bit of security for a whole lot of economic benefit.

Without centralized, trusted gateways, it's not even clear that your communications are secure. They need to be centralized to make them easy to monitor and audit. With a distributed trust model, the compromise of one node can be catastrophic; all you're really doing is handing control of the trust network over to botnets.

This is a really hard problem. I can't think of a better solution that would serve the same niche as our current one.

tptacek8• 12 years ago

What you want is Moxie Marlinspike and Trevor Perrin's TACK.

It is already the case today that for Chrome and Firefox users, a compromised CA can't easily hijack connections to Google Mail. Not only that, but any attempt to hijack Google Mail connections in the large will run aground on Chrome and Firefox users, who will not only not accept the rogue certificates, but will also alert Google, which will put a gun to the head of the CA.

The feature that enables this is called certificate pinning. It works well for small numbers of high-profile sites, but requires manual intervention on the part of browser vendors.

TACK pushes certificate pinning out to site operators. It works like HSTS: the first connection to a website is trusted, and that connection loads up state that the browser holds. Subsequent connections check for consistency with the first connection. Dynamic pins, or "tacks", make dragnet surveillance of all sites asymptotically as risky as spoofing Google Mail. The attacker is nearly certain to accidentally catch someone with a tack loaded, and at that point the game is up: the attempt to present an otherwise-valid certificate that violates a tack is a smoking gun, to which Google and Mozilla ca respond with their own firepower.

The nice thing about TACK is that it works alongside the CA hierarchy, and even derives some value from it. A tiny fraction of the Internet could adopt TACK and still make life much harder for attackers. The effort required from site operators is small, and the whole system is invisible to end-users.

Fixing the CA hierarchy is a lot less sexy than ground-up rewrites of the whole Internet security model. But the ground-up rewrite is never going to happen, and the incremental fixes are not only doable, but doable by the kinds of generalist developers who are champing at the bit to stick it to the NSA. The biggest security problem on the Internet isn't protocols; it's browser UX.

Tomte2• 12 years ago

Isn't that a bit like Opportunistic Encryption (which I happen to consider a neat idea)? Or do I misunderstand that?

I'm asking, because I dimly remember you not being a fan of OE -- have I confused you with someone else there?

tptacek8• 12 years ago

I'm not sure how TACK is similar to OE. OE is encryption without meaningful authentication. It's an open invitation to MITM. I'm definitely not a fan.

patio11• 12 years ago

Not only that, but any attempt to hijack Google Mail connections in the large will run aground on Chrome and Firefox users, who will not only not accept the rogue certificates, but will also alert Google, which will put a gun to the head of the CA.

This is one of those "Things which somebody would probably bring up at an anti-trust meeting if anybody at an anti-trust meeting had the foggiest clue of what was going on", incidentally. (The hypothetical threat is "You give our web properties a better SLA than anyone else in the world gets, or we will use the coincidental fact that a large portion of the world's web traffic runs code under our control to end you.")

It's funny, people (including me) always thought that Google's big swinging Wand of Annihilation was google.com, but now they have at least four of them.

lstamour• 12 years ago

And here I thought the "gun to the head" was more of a "smoking gun" -- as in, hey, that MITM attack you thought you could get away with? Yeah, we noticed.

kbenson2• 12 years ago

It's not just google properties, the Strict Transport Security sectionof the chromium dev docs [1] lists multiple properties they do this for (for example, twitter and paypal), and it appears you can specify your own as well through the command line (and probably elsewhere).

[1] http://dev.chromium.org/sts

personZ• 12 years ago

Why would that be an anti-trust concern? What Ptacek is referring to is a CA compromise being detected. At that moment the CA would be, quite correctly, with a gun to their head as their entire purpose for existing -- their whole business model -- would have evaporated.

syjer3• 12 years ago

TACK is really cool, but is it still pushed to the vendors? (Or even, are the vendors interested?). I've seen patches floating on github, but alas, not that much activity lately.

tptacek8• 12 years ago

The vendor space, considered seriously, consists of Google, Mozilla, Apple, and Microsoft.

Of those four, Google is pushing hardest for CA-compromise countermeasures.

Google's current preferred solution is Certificate Transparency. I don't love CT, for reasons very similar to those that the typical HN reader would come up with after reading it, but it's still a step forward.

We sponsored development of some TACK code last summer, but none of the browser vendors are itching to integrate TACK. Google has nice things to say about it, but "backburnered" would be a fair summary of where it stands right now.

itistoday25• 12 years ago

This has been discussed multiple times now [1], but TACK is not a solution because:

1. It amounts to a preservation of today's pay-for-security system (the no-so "nice thing" you mentioned), which is not necessary. It is not necessary, thanks to distributed databases like Namecoin, to have to pay for SSL certificates anymore (or fax credentials, or any of that).

2. It doesn't offer a strong mathematical proof of authenticity the way a blockchain-based solution does. [1][2]

[1] https://news.ycombinator.com/item?id=7325551

[2] https://github.com/okTurtles/dnschain

syjer3• 12 years ago

TACK has the advantage to work in the current infrastructure (with some patches): it's a point that should not be ignored if you want wide acceptance.

jmspring2• 12 years ago

"The biggest security problem on the Internet isn't protocols; it's browser UX."

I think it is security UX in general. Anything around certificate issuance/life cycle (SMIME or PGP signed/encrypted mail), PGP key exchanges, etc. That problem has not been solved.

gjm11• 12 years ago

Meh, he's only saying that because TPTACEK loves his PET TACK.

IvyMike• 12 years ago

What exactly needs to happen for TACK to go widespread at this point?

Maybe we can get some good out of this week's focus on security.

danielweber• 12 years ago

I'd say to just get the word out. Around this time last year I was working at a security company and personally pushing for establishing automatic TACK protection for our clients, passively sniffing certs for SMB networks and learning which ones were good, but no one else knew what I was talking about, I couldn't convince them the project wasn't dead, and at the time I couldn't answer the question "how do we deal with a legitimate change in browser cert."

If you can grok TACK better than I do at the moment, start writing patches for web servers.

tptacek8• 12 years ago

Best next step would be to get some non-browser user of TLS to rely on TACK.

belorn• 12 years ago

If TACK can rewrite the trust model away from the CA and into the state of subsequent connections, we won't need the actually CA. Self-singed certs are equally fine to establish trust after first connection.

If however we do use CA's as the trust model in order to trust the first connection, then TACK is nothing but a policy system to attempt keep CA honest. Users would still need to put their trust to third-parties that they never meet, and who's priorities and objectives are unknown.

tptacek8• 12 years ago

I see TACK as a decisive mitigation for the biggest danger posed by CAs today (that they enable global passive adversaries to conduct dragnet surveillance), and as a step towards a workable web-of-CAs system.

I do not believe in pure peer-to-peer schemes as workable solutions, but I do believe that we could in 5 years have a system where I can trust ACLU first, and then Verisign as a fallback.

xyzzy1232• 12 years ago

TACK looks cool. I read through the RFC and have some questions ....

At first I thought an active MITM could drop TACK negotiation from ClientHello and wait 30 days until pins expire, but as I read it, I think that should result in a "contradicted" pin.

You could do browser profiling though, and only MITM clients which don't send a TackExtension in the ClientHello, or behaviourally look like IE, say. I wonder if it would have been better not to indicate that client supports TACK? (Maybe constraints not obvious to me).

The other thing I'm not sure about is overlapping TACK handling. I don't see what's to prevent an MITM from adding an additional new TACK of their own in the ServerHello, gradually superseding the "valid" TACK. That would take like 60-90 days though.

This looks like a massive improvement, although I wonder if it actually protects clients which do not support the extension?

tptacek8• 12 years ago

You could do that, but you'd be outed immediately by anyone who checked two TLS connections back-to-back for consistency.

hueving2• 12 years ago

This looks like a massive improvement, although I wonder if it actually protects clients which do not support the extension?

Only indirectly through network effects. It's much harder for a valid attack certificate to stay undetected in the wild when a subset of the people you might attack are running TACK. You're right that it might not help clients if the MiTM software intelligently avoids attacking TACK-capable clients.

billpg• 12 years ago

"the first connection to a website is trusted"

Yeh, I can't see that going wrong any time soon.

thefreeman3• 12 years ago

That threw me off too. But I think they may mean the first visit ever. Meaning it would be something they could control and validate before releasing to the public?

brazzy• 12 years ago

Nobody is claiming that it provides perfect security, but it massively reduces the attack window for successfuly certificate spoofing, while turning any failure to hit that window into a big red blinking alarm sign.

ChuckMcM2• 12 years ago

Sigh, nice try but it doesn't work. It does remind me of the adage that goes, "For every complex problem there is an answer that is simple and wrong."

The web of trust model doesn't scale, that was made abundantly clear by PGP when it first came out. Even Phil Zimmerman, the guy that practically invented it, agreed it didn't scale and something else was needed. X.509 came about not because some person foisted it on the universe, rather a bunch of people who were writing security systems at the time (myself included) got together with other cryptographers, engineers, and administrators under a group hosted by "Public Key Partners" (the folks collecting together the Patent pool associated with public keys) and tried to come up with ways this might work.

It has had some fabulous successes, certificate authority compromised? Pull their root cert and blam none of their keys are trusted any more. It had some failures. Call the baby ugly if you must, but at least propose something that hasn't already been tried and shown not to solve the problem.

[Edit: I really need to keep peoples names in different buckets in my head]

acqq• 12 years ago

For me, the major problem in the infrastructure of PGP "web of trust" is that even that is prone to spamming (not in the hash values but in the appearance of names involved) and learning to avoid them. See the recent example:

http://cryptome.org/2014/04/radack-greenwald.htm

It doesn't appear at the moment that pushing this technology to web browsers would increase the security of the most of the users.

zanny4• 12 years ago

It doesn't really solve OPs points though, the largest of which is that certificate authorities are a closed off oligopoly. But we have literally no way to trust them, even beyond the CA price gouging, because any state they are located in will just seize their keys and read your traffic.

ChuckMcM2• 12 years ago

Trust me zanny, I'm not picking on you, I'd like to examine your three claims in a bit more detail:

1) "certificate authorities are a closed off oligopoly" - This is absolutely not true. Pretty much anyone can start their very own Certificate Authority. The code isn't that complicated (the specs are all available), the math is no longer patented so you don't have to pay tributes to PKP. What you do have to do though is convince three people you're trustable, Mozilla, Microsoft, and Google. If they add you to their trusted root certificate list then you've covered a whole ton of the market. I know of at least one "private" certificate authority which shares its ROOT CA with individuals who want to trust that the sites which have a cert from them is "legit." (for some definition of legitimate).

2) "any state they are located in will just seize their keys ..." - this conflates two things, one is trust and one is seizure. If you live in the US, and have a PGP key that is trusted by the target of an investigation, and law enforcement can convince a judge that using that is the only way for them to get the proof they need, you may find yourself on the receiving end of a subpoena which demands you hand over access to your key. You can refuse of course, and the court can put you in jail for contempt. This issue is completely separate from the Certificate Tree or Web of Trust choice. The purpose of the certificate is to establish trust not privacy. The purpose of the TLS protocol (aka SSL) is to establish privacy. Its necessary (but not sufficient) to be able to trust the other end.

3) "... and read your traffic." - Which is a violation of privacy relates to how you established privacy as opposed to the mechanisms in that protocol. And I suspect that you think that is a splitting semantic hairs but bear with me for a moment. The heartbeat bug is in OpenSSL, not the certificate infrastructure. There are lots of things that used different protocols, and X.509 certificates, that are just as secure today as they were before this bug was disclosed. The key here is that they used a different protocol.

The OPs rant might more properly be leveraged at what is effectively a mono-culture around OpenSSL, and I would agree that is a bad thing, but to not have that be the case you would have to have people write their own TLS libraries. And while that would assure that vulnerabilities were contained, it won't happen because nobody can afford these days to hire a programmer to write TLS libraries that the only 'hire' has been someone coding up some Javascript and CSS.

I can completely relate to the OP's angst over the challenges of keeping things secure in today's world, its something of a life we "chose" relative to using open source.

einhverfr• 12 years ago

The problem though is that you lose any external trust.

Now external trust is not very helpful for some things. It won't protect you from state-sponsored MITM attacks. Also non-EV certs may not inspire a whole lot of trust.

But you have the fundamental question which X.509 tries to answer: "Before I give you my credit card number, how do I know you are who you say you are?" You need some form of external trust there to answer that question.

External trust is not foolproof. See Thompson's important paper on the limitations of it. However, it is very good at addressing certain classes of threats (and very bad at others).

In the end we need both models and there is no real way around that.

BoppreH• 12 years ago

PKI is the worst form of authentication, except for all the others.

I like to design secure protocols for fun, and they all inevitably converge into a PKI when you start adding the non-trivial required features. It's incredibly frustatring.

mike_hearn3• 12 years ago

I wrote an article called, "Why you think the PKI sucks but can't do any better" that goes over every single proposed alternative to it and explains why none of them work:

https://medium.com/p/d04ea6a2c771

It's also got links to various security usability studies that are required reading for anyone who cares about this space.

tl;dr - the article is dumb, heartbleed doesn't even have anything to do with X.509.

jessaustin2• 12 years ago

He who controls a Queen can make functionally equivalent copies of every Princess and Princess-baby in the Queen’s lineage. They have the skeleton keys to your ‘secure’ kingdom and could at any time decide to become a fraud factory and dish out copies of your keys to whomever they fancy.

In a sense, it's worse than that, because a "queen" can actually sign (correctly or not) any "princess-baby" in any "lineage".

PhantomGremlin• 12 years ago

YES YES YES, 1000 TIMES YES!!!!

Unfortunately not too many people know this, and it's a really important issue.

BTW like a lot of other people here, I didn't like the "Queen" analogy. IMO it didn't make the explanation any simpler.

elchief• 12 years ago

Anybody know which, if any, of the SSL cert vendors don't use OpenSSL?

jboynyc• 12 years ago

Previous HN discussion on Monkeysphere, a Debian project which implements something like what the author envisions: https://news.ycombinator.com/item?id=6617132

And the description from the Monkeysphere site on why they are a better alternative for HTTPS: http://web.monkeysphere.info/why/#index1h3

infinity0• 12 years ago

Indeed, this is pretty much exactly what the OP is talking about. The problem is that it's hard to bootstrap, since correct verification procedures are not widely-known.

TACK, what tptacek mentioned, is an orthogonal strategy for solving the same problem, but it assumes that some MITM will be detected. An ideal solution would involve a combination of both TACK and monkeysphere.

aidenn0• 12 years ago

There's also convergence, which currently can work for the case where the client is undergoing MITM, but not the server. Add support for notaries to cache TACK responses and you are pretty secure.

jmspring2• 12 years ago

The article makes a generalization that is not correct in most cases around certificate request and issuance --

"And fundamentally you have to trust that they who hold the Queens aren’t dishing out copies of your certificates."

The entity holding the Queens can give out a copy of your certificate, sure, but in most cases, they do not hold the crown jewels -- your private key -- which is the part of the Heartbleed bug that is really bad.

There have been cases of CAs either issuing or being compromised and issuing new certs which duplicate a site identity, but that is different then releasing the private key of a particular certificate.

abalone• 12 years ago

tl;dr: Don't trust big scary corporations like Symantec to verify sites, trust your friendly local geek's network.

I think if you weren't exhausted by the sheer length of the post by the time you reach that proposal tucked at the very end, you might think to ask some critical questions. Like, what are the vulnerabilities and exploits of a peer-to-peer system? Would this not be open season on socially engineering average folks to trust the wrong peer? How vulnerable to attack are local geeks and university computer science departments? How are compromises noticed and handled by the average folks who trust a small local authority? How will the verification work be paid for, or will it be completely volunteer based, and how efficient will that be?

Moreover, what the author fundamentally misunderstands is the importance of usability in security. Web security isn't perfect but that's because more perfect security would make ecommerce annoyingly difficult. Then people start taking shortcuts or just ignore security completely, which is a worse outcome. It's not enough to point fingers at users and yell that they're doing it wrong; security architects have to take responsibility for security outcomes. A peer-to-peer system would be significantly more inconvenient for average folks to use correctly, if only because of figuring out who to trust in the first place.

politician5• 12 years ago

Well, to be fair, the author raised the UI/UX question which could be a great way to overcome the bullshit "green padlock == safe" idea. Which it doesn't now post-Heartbeat, and never did.

A different UI might reveal the trust path more directly, so that if I navigate to my bank that path might be forced into view.

I, for one, would love it if my browser displayed the trusted path used to connect to my bank before loading any part of the page. The same goes for self-signed certs. Would I avoid HN if their cert was self-signed? Nope.

pskocik• 12 years ago

This seems like utter nonsense to me. Certification authorities should never get to look at my private key, and I don't care about them giving out my public key (it's public, after all). The best they can do, if they're evil, is create a new pair with information that impersonates me.

nardi• 12 years ago

The missing piece of this for me is: How do we fix X.509 for mobile apps, considering 80%+ of mobile usage is in apps, not browsers?

avodonosov• 12 years ago

OMG, you've exposed all those intruders-oligopolists!

spiralpolitik• 12 years ago

Not going to happen because the main OpenPGP implementation (gpg and gpg2) currently has a non permissive license that as such that it cannot be used "Everywhere".

Until there is a implementation of OpenPGP that uses a permissive license, getting the world plus dog to switch to PGP is a non starter.

PeterWhittaker• 12 years ago

I’m not a cryptographer; nor am I a hard core C guru; nor have I invented some brilliant library that gives me street cred to talk about this stuff. I’m a nobody.

But somehow I am qualified to inform the world as to why PGP is superior to X.509.

I'm not debating that point, and informed debate would be welcome. And I have to say that I find it refreshing for a blogger to so inform me in the first paragraph as to just how quickly I should skim through or close their rant.

I really did appreciate that. Though somehow I find myself investing more time in the writing of this comment than in the consumption of the article. Fortunately, like floss, 't'will soon be forgotten.

kijin2• 12 years ago

I would much rather trust a handful of multinational corporations than a group of "local geeks" to tell me which keys I should trust.

Why?

1) It is probably easier for casual attackers to trick a local geek to trust a phony key. Determined attackers and state-level actors can probably compromise CAs as well, but most day-to-day threats are of the casual type.

2) When a local geek accidentally trusts a phony key, and other people realize it and point it out to them, all that happens is "Oops, I'm sorry." When Comodo is caught issuing phony certificates, there will be a Silicon Valley-wide uproar, browser vendors will very quickly invalidate the offending intermediate key, and the incident will hurt Comodo's bottom line for many years afterward. In other words, Comodo is more accountable than any private individual, not because it's any more ethical, nor because it is any more competent, but simply because it is a highly visible target of public scrutiny whose very survival depends on its public image as a trustworthy CA.

3) Most people (including but not limited to grandmas) who are just beginning to use the Internet have no way to know which keys to trust. We in the programmer community are an exception, not the rule. So what's actually going to happen is that browsers will trust, by default, a bunch of highly reputable individuals or groups (perhaps the browser vendors themselves) and advise the user to trust whomever these people trust. That's not really different from the current situation with CAs. We just replace Verisign and Comodo with @cperciva and @tptacek.

atmosx• 12 years ago

It is probably easier for casual attackers to trick a local geek to trust a phony key. Determined attackers and state-level actors can probably compromise CAs as well, but most day-to-day threats are of the casual type.

Not true, see here: http://privacy-pc.com/articles/ssl-and-the-future-of-authent...

Problems here is that free market model doesn't work once you're a big player. Instead of Comodo being bashed by MS/GOOG/Moz it's sill there all shiny and bright serving SSLs.

So the current model is flawed and can be exploited by technically unskilled users, but worst than that, it doesn't seem to care about it's failures.

TeMPOraL• 12 years ago

I strongly disagree with your point 2). The reality is, if Comodo is caught issuing phony certificates, there's some media shitstorm that never actually changes anything, stocks go up and down a bit, and few days later nobody ever remembers any it or cares about it, and the company continues doing it's business as usual (don't believe me? then why GoDaddy still exists?). On the other hand, we have social mechanisms for dealing with mistrust in place since forever. If you are caught untrustworthy once about something, you'll probably never be trusted again on that issue. People know how to deal with those situations effectively between themselves. It's also easier to boycott an untrustworthy peer than a multinational corporation. You have many friends to choose from, but there is usually no other company to go to for a comparable service.

kijin2• 12 years ago

we have social mechanisms for dealing with mistrust in place since forever ... People know how to deal with those situations effectively between themselves.

As some of the other commenters have mentioned, the problem seems to be that these social mechanisms don't scale.

Please take my point 2) in combination with point 3). As I said, techies are the exception, not the rule. It's not just Grandma who will have trouble with a web of trust, it's pretty much everyone except us. How do they even know which peers to distrust? Will there be a news feed about compromised peers? Will everyone have to subscribe to one? What if someone wants to explore a part of the web that none of their peers, or their peers' peers, have ever heard about?

The single most important advantage of a centralized model of trust is that a list of trustworthy vs. untrustworthy parties can be quickly and widely distributed in an automated fashion. Comodo issues phony certs? 12 hours later, every copy of Firefox receives an updated list of revoked keys. I know it doesn't currently work like that, but it's entirely possible. Whereas with a web of trust, millions of people will be left trusting compromised peers for many months afterward because they didn't get the news.

mrerrormessage• 12 years ago

Surely if Zuck got half the world signed up for a network that does nothing but suck our eyeballs in return for money out of advertisers pockets, we could get a few million, even say, 10-20 million people using PGP. Remember that Tor was once considered a niche tool as well.

weavejester3• 12 years ago

The Queen/Princess/DNA analogy was more confusing than actual system of certificate signing.

The author also underestimates the consequences of performing a MitM attack with a root certificate. MitM attacks can be detected and a copy of the signed cert is proof. If the NSA were abusing a root cert, there is a chance it could be noticed.

So what if it was? Well, that certificate would be removed from browsers and operating systems. The CA would be placed under suspicion. In a worst case scenario, the CA could be completely ostracised, perhaps even to the point bankruptcy. An abuse of a root certificate could potentially do hundreds of millions of dollars worth of damage.

That's not even covering the diplomatic fallout. If the CA points the finger at the NSA, the President would have to explain why the target was so important that it merited destroying part of the root trust system of the Internet.

There are far less messy ways of dealing with a high-value target. I'd be more concerned about other zero-day vulnerabilities the NSA might have found.

politician5• 12 years ago

If one of the Big 4 were compromised (which we should all agree is most probably the case for all of them), even then, "too big to fail" rules the day.

It's vanishingly unlikely that Google, Microsoft, and Apple would remove a Big 4 CA root cert and break the trusted path of 25% of the secured market.

weavejester3• 12 years ago

It wouldn't just be the browsers removing the CA. There would be a strong incentive for websites to switch as well, particularly foreign ones, so you'd find a mass exodus anyway, even without browser support.

Browsers don't have to turn a root CA off all at once, either. They could start by turning off Extended Validation for the compromised CA, or they could release a statement saying that if they don't get guarantees this won't happen again, they'll remove the CA in a year's time. They could allow connections, but change the SSL icon to indicate the certificate has been compromised. Browsers have a lot of options to put pressure on root CAs, even without removing the cert.

lorddoig6• 12 years ago

Again though this argument rests in people choosing to behave a certain way: CAs will choose not to go rogue because browser vendors will choose to be outraged by it.

If one was to attempt to formally specify X.509 in terms of math or logic we'd get to this part and have no choice but to write "the security of this portion is because we say so". How many times must we be betrayed before this isn't good enough?

weavejester3• 12 years ago

Security is always going to involve trust. Even putting aside root certificates, you'd still have to trust your browser and your operating system.

That's not to say there aren't better mechanisms for verifying trust, but you'll never eliminate it entirely. There's always going to be some assumption, such as "the central authorities are trustworthy" in the case of SSL, or "the majority of nodes are trustworthy" in the case of Tor, or "the CPU majority is trustworthy" in the case of Bitcoin.

ClashTheBunny• 12 years ago

This already exists: http://web.monkeysphere.info/

joeblau• 12 years ago

I used to work on PKI and this right here would have the old guard of system security architects up in arms:

  > 90% of that guff can be automated and hidden underneath a good UI, but can we
  > dispense with the need for key exchange parties? Absolutely we can.

So who builds this "good UI that everyone trusts"? Without details of how this works, there is no way this system can grow. There is no way to have efficient key exchange except though an arduous process of everyone creating this mesh of trust manually. PKI creates this "good UI everyone trusts" with a bad UI that everyone trusts which has turned into these 4 companies that are mentioned in the article. It sounds good, but it's an iron triangle.

Nursie• 12 years ago

Heartbleed and X.509 are basically unrelated aren't they?

The OpenSSL bug that allows heartbleed is nothing at all to do with the (many) flaws in the public trust system.

The fundamental problem here (as I see it) is that you're trying to set up trust between parties that have no existing relationship. This requires third parties and externalised trust whether you use a CA or a P2P net.

Either way, it's nothing much to do with heartbleed, which would have leaked the keys to the kingdom under either model.

negamax• 12 years ago

Next 10 years will be all about decentralization of every infrastructure and institution. Only in a trustless system we can have any chance at trust. So no CAs, no authorities.

lorddoig6• 12 years ago

A follow up for the keen and eager

http://lorddoig.svbtle.com/should-we-make-a-working-group-to...

mcgwiz• 12 years ago

Rather than all the engineers and tech-minded people here naysay the idea into oblivion, I think it's worthwhile that we encourage designers to take an earnest stab at this problem.

The complaints here are basically "w.o.t. is not usable", but that's basically what the author said. He therefore also indicated this is as much a design problem as anything else. That's a useful insight we shouldn't dismiss, at least not until some thoughtful, imaginative designers have actually taken a crack at it.

Heartbleed should bleed X.509 to death

Related Stories