Hacker News Reader

Comment by lorddoig | Hacker News Reader

Being told that you now trust someone with your secrets via a news website is a pleasingly succinct display of everything that's wrong with the CA model.

View on HN

Well. The CA model is community trust. I am told all the time, often by news websites, that my government now trusts or distrusts some other government, that my employer now trusts or distrusts or is even part of some other company, etc. I don't know if I personally think that the embargoes on Cuba should be lifted, or my company's new vice president is qualified for the role, or (if I worked for VMware) Dell is a good employer, or my savings should now be held by Bank of America, or whatever. But that's how living and working in a community works.

If you have secrets that are too sensitive for community trust, there are other mechanisms, but they typically have trouble scaling very much beyond continuing a previous face-to-face relationship. For the question of whether, say, news.ycombinator.com is who they say they are, I don't care enough to take Caltrain down to YC's offices and check a fingerprint posted on the wall, if they had one. What I care is that, at scale, the certificate authorities I trust will do a good job of verifying identities and running secure systems.

And I am not an auditor or pen-tester of large companies, and even if I were, I wouldn't want to spend my spare time auditing and pen-testing all CAs just before I can use the internet. (Importantly, I am not an auditor of web browsers or SSL implementations either, and since I outsource my trust to my browser / SSL stack, it's not useful for me to be skeptical of the CAs unless I'm also skeptical of the code.)

Remember that the CA model is bare-minimum security. (Some of the CAs find money in telling you otherwise, but they're stretching the truth.) All it's providing is the security that, in a perfect world, you would have gotten all along from DNS and IP. If you need anything more than bare-minimum security, there are tons of options, ranging from the SSL-based (EV, HPKP) to the completely unrelated (PGP, Pond, etc.). But the world needs a good mechanism for the simplest security that could possibly work, and the CA system seems to have settled into that role.

CAs are CAs because they established themself. Personally I don't trust them because they are susceptible to MitM attacks & government intervention attacks.

Some Mesh Networks & protocols like the Tor Browser use an IP derived from a public key.. so you're absolutely sure that who you're talking to is who they say they are.

Why can't we have our cake (long distance electronic communications) and eat it too? (encryption & assuredness of identity)

Celebrating "trustedness" of LetsEncrypt only perpetuates the belief that CA is working fine.

EDIT: See below discussion by other posters

We’re pleased to announce that we’ve received cross-signatures from IdenTrust

This is what is wrong with the CA, model, not their method of announcing it to a community anxiously awaiting the arrival of their product. What is absurd is that identrust has a shitty non-responsive 90's looking website and wants $299 for an SSL certificate, which is something that should be free. I will say though, they really did sell me on their trust worthiness with the alternating images of a fingerprint and a lock. So now I know they're legit. It is worth the $99 for SSL on a single site annually because there is binary data superimposed on some of the pictures.

I don't think he was saying they acted poorly by announcing on HN, but that he would prefer to grant someone trust rather than have it forced on him before he even knew about it. Not an easy task for a functional web, but it would obviously be better if possible.

There's many ways, all obnoxiously complex unless you go back to a CA-ish voluntary trust model.

Keys as addresses (I2P, Tor hidden services, CJDNS) fixes a large part of the security problem, then on top of that you can add your choice of address translation. WoT style individualized trust webs? Trusted lists of name assignments DNS style? First-come first-serve á la Namecoin?

Not necessarily. You could also place domain validated trust in the registrars, to cryptographically verify their delegations. That would build a chain of trust which you in turn could use to validate keys for services in those domains.

That's the DNSSEC+DANE approach and that's still the same as the DNS approach I listed (trusted name registry lists), except that the address isn't an IP-address (or in other words, your domain's DNS server that says what IP addresses your subdomains have is itself identified by a public key).

Your last three sentences are sarcastic nerd-rage (with which I completely agree), but your boss (not _your_ boss, necessarily, but the more generic/stereotypical "your boss") utters those words in complete earnestness...

link: https://www.identrust.com/

Nothing you said is a reason for not using Let's Encrypt.

To be clear, I am massively excited to use Let's Encrypt and plan on setting up SSL for the first time ever when it launches. I am legit broke so I can't afford to pay a lot of money for someone to have an automated process of:

    gpg --gen-key

I was responding to parent, that announcing trust is a werid quirk of the CA model. TBH, that is correct, but I find it more bizarre Let's Encrypt has to be "trusted" by an unknown company that no one really knows anything about. That is the bit I find weirdest.

Although I loved your sarcastic remarks about the cool pictures, I do want to point out that there are two issues with your argument:

a) There is something else that you know about IdenTrust, and that is that your browser vendor trusts them. This is the whole point of this CA thing: in the end you trust whom your browser vendor trusts (with the option of removing CAs for which you disagree). This is far from perfect (especially since the vendors' vetting process can be quite opaque), but it is not nothing - after all, you should trust your browser vendor, otherwise all the encryption of the world can't save you from someone eavesdropping on your websurfing.

b) Your argument can be read (or misconstrued?) to state that it would be perfectly reasonable to trust IdenTrust if they had a 2015-looking, professional website written in Angular and node instead. Which, of course, is not the case as many who entrusted their money to fraudsters with professional looking websites will be able to attest to.

You raise some good points, and I totally agree. The thing is, when the drduh Yosemite guide came out (around the time Google dropped CNNIC) I looked into it a bit. I dropped a ton of certs, mostly international ones (about 40) and the only site that broke was Bing.

> you trust who your browser trusts

Exactly, and my OS. But I run Mac and I am sure Windows users can relate, there are over 200 CAs and I have no idea what heuristics can be used to determine whether they are trustworthy. It wouldn't be a big deal except a compromise at ANY means they could fake ANY website.

Now, on a serious note. If you were running node and you had a super clean react front end with a picture of Jamie lee Miller from hackers super imposed over the ghostbusters symbol (responsive using html5 flex boxes) for sure I would trust you with the security for every website I visit.

I just meant the comment more as idem trust looks like a random rent collector who hasn't updated their business model since 1995. As a broker of trust, I find it disconcerting I know fuck all about them and even if I did, there are hundreds more like that. If you have the money, I don't because I am broke, for sure it would be worth $100 for a padlock when a user hits your site. With nothing more to go on than their site though, it looks like they have been on autopilot for 10 years and I can't wait for Lets encrypt to go live.

An encrypted communication channel specifically doesn’t say that you trust the person at the other end with your secrets. It means that you both agree that the secrets being transferred are safe from 3rd parties.

It might not say that you trust what the person at the other end does but it does indicate that a third-party has vetted the identity of the person at the other end. Do you trust Google? Probably not with everything but you do trust that the certificate that was issued to them proves that they're at the other end of your search bar.

OK, but that’s only with EV certificates. No-one issues EV certificates for free, especially not Let’s Encrypt:

Let’s Encrypt has no plans to issue EV certificates at this time.

https://community.letsencrypt.org/t/frequently-asked-questio...

You would like to buy a knitted scarf from a yak herder in Ecuador. How do you propose that establish trust between you and the yak guy without an intermediary?

Pictures of the yak sent by Snapchat, of course.

I'm imagining snickering goats on the other end, uploading yak photos from a stock image website. =)

Crypto currency with escrow, receipt of goods validated by a robot camera sending a picture to an anonymous network of validators who say "yep that's the scarf they ordered, trigger the payment"

That system still appears to include intermediaries. They're just stuck in a Rube Goldberg machine rather than dealing directly with the two parties.

Good point. I don't think there's a solution.

What's wrong with intermediaries?

The commenter above implicitly rejected intermediaries. To me it is clear that my browser is a trusted intermediary, and part of my trust in them extends to letting them decide whether to trust IdenTrust. And part of my browser's trust in IdenTrust extends to letting them decide whether to trust Let's Encrypt.

In the yak-herding analogy, Let's Encrypt is a new charity in Ecuador that provides market services for scarf knitters. IdenTrust is a large regional trader in South America. My browser is the local yak-scarf store down the street. It seems totally obvious to me that, in this case, of course I'd hear about IdenScarf making deals with Let's Shave Yaks on the news. But the parent commenter is unhappy about the local yak store not being directly involved, and thinks it's some form of failure of the global yak-scarf supply chain that an individual consumer isn't part of that conversation.

I'm not sure what you're getting at. Care to elaborate?

New wannabe CA Entity B can approach an established CA entity A, convince A to sign B's root or intermediate cert, and then B can forge browser-trusted certs for every SSL website on the net that's not pinned.

In this case, B is LetsEncrypt and is (hopefully) pretty solid, but that isn't always the case. Earlier this year, it became known that CNNIC had issued a CA cert to MCS Holdings (of Egypt), which then did bad things.[1]

The news that everyone is suddenly trusting a new entity B, whether it's some Egyptian IT firm, or LetsEncrypt, comes out of nowhere. Neither cooperation nor even awareness is needed of the major browsers' dev teams.

[1] https://googleonlinesecurity.blogspot.com/2015/03/maintainin...

How is this any worse than trusting the original CA? There's almost assuredly some high standard they use to cross sign, and they'd get revoked if they do that incorrectly. You're failing to note that MCS was revoked as was CNNIC. So, boom, 2 bad/laughably incompetent players are out.

Trusting a CA means trusting them to write certs, even via an intermediary. If you don't actually trust them, remove those CAs.

The CA model has lots of problems, but I don't see what additional harm this actually causes.

Because it doesn't settle with having as many single points of failure as the number of CA entries in your root CA list, they are getting multiplied over and over.

How would it be any different if these CA's made a choice to instead issue end-user certs but based off of Let's Encrypt's authorization?

Fewer master keys to target

I'm gonna guess that getting into Let's Encrypt's HSM is as hard or harder than breaking their auth procedures.

Is it (technically) possible to limit CAs validity to certain subset of.. something? I.e. certain CAs could only be used to verify limited number of.. domains? something?

If you're talking about limiting to certain TLDs, like American CAs not being able to issue .ca or .in or .paris, there is a spec for that, called name constraints. It is intermittently supported, and there was a thread on mozilla.dev.security.policy, primarily focusing on government CAs, which argued that doing such a thing fractures the open/egalitarian nature of the internet, by making zones where security is less important:

https://groups.google.com/d/topic/mozilla.dev.security.polic...

I can imagine other ways you would restrict certificates (for instance, I'd kinda like to see a spec for a "half-CA", where you need two half-CAs under distinct organizational control to sign you), but I don't think anyone has specified the problem for those precisely, let alone proposed a solution.

Yes using "Name Constraints" but that RFC / extension is really broken, and implementations don't support it. See 4.2.1.10 of https://tools.ietf.org/html/rfc5280.

That's how SPKI (RFCs 2692 & 2693) worked: one only trusted an authority for certain things. This would work very well for DNS names and IP addresses alike, since both are allocated hierarchically; with SPKI one could guarantee that one is talking to one of the parties who is allowed to use a name or an address.

Sadly, SPKI more-or-less died on the vine: the atrocious XPKI 'system' won by default. One of my rainy-day projects is to try to revive it: if the last 15 years have taught us anything, it's that centralised global trust is insane.

AFAIK, no it's not. However, this is the solution as far as I see it. When you buy a domain name from a registrar they should give you a mini-CA that's valid for just that domain for as long as the domain is registered. Then it's up to you to create and sign any certs for any subdomains. This would cut out the CA businesses entirely, enabled security-by-default, and simplify the whole system.

Probably just that we're being told who to trust, instead of deciding who to trust.

I guess we could have some kind of web of trust system instead. But are there any web of trust systems that actually work in practice?

Allowing multisignature models would at least drop the single point of failures, by being able to require verification from multiple CAs. In combination with certificate transparency and DNSSEC+DANE it would add much stronger security.

So you trust yourself more than everyone behind Let's Encrypt, et al? Of course, you don't have to use Let's Encrypt so you do have a choice.

I think the criticism was meant as one of the CA model, not Let's encrypt specifically - you have no choice about using CAs if you want to use https to serve a site to normal users. Also, I'm not the OP and think Let's Encrypt specifically is a great idea, already on the waiting list.

Reply on news.ycombinator.com