Hacker News Reader

Comment by FDSGSG | Hacker News Reader

What problems would decentralization solve here?

Competition is always good. For one, a completely decoupled and separately managed system on a different stack would improve availability of ACME-based certificates. It would also reduce the concentration of trust in one entity. While LE is awesome, the target on their back is only getting bigger.

For what it's worth, I'm pretty sure even Let's Encrypt wants to see competitors to Let's Encrypt.

> It would also reduce the concentration of trust in one entity.

No it wouldn't. If there are 9999 CAs, you need to trust every single one of them.

A better argument for having multiple CAs is that it would increase resilience (against takedowns, bugs, money running out, etc.)

Convergence was a project to have multiple notaries to vouch for a TLS certificate instead of a chain of CAs.

There are way to decentralize the internet, but there never will be much interest for it.

Extremely funny video by Moxie Marlinspike about it:

https://m.youtube.com/watch?v=Z7Wl2FW2TcA

Thanks, in some twist of irony, I’ve mistaken Convergence for Perspectives.

I think you’re interpreting my comment about trust too literally. If you’re talking about “Web PKI root of trust” trust then yes, having two CAs just means you’re trusting two third parties without reducing trust in either. I was using the term more broadly and more narrowly... like, trusting them to be good stewards, trusting them with PII, and trusting them to not configure their DNS resolvers to use NSA-controlled DNS. They have more power and more control and become a more attractive target and more susceptible to corruption because the stakes are higher. Maybe I should have said “concentration of control”. If one CA owns 90% of issuances they’ll be able to push their agenda, for sure.

To be clear, all of the evidence shows that LE uses this power only for good. But that’s the threat. 30% market share is probably fine. 90% or 100% would be scary.

I agree => small question: in this context wouldn't "diversification" be more appropriate than "competition"?

In this context I think they are the same.

If you're working for profit, competition is awful. If you're not working for profit competition may or may not be good. Regardless, how you personally feel about competition isn't relevant here.

Limiting a bit the impacts if Let's Encrypt is compromised in any way.

If Let's encrypt is compromised, either by being able to issue certificate for arbitrary domains or if the CA itself is compromised, the impact would be huge given the current number of certificates signed by it and this number is likely to grow in the futur.

With several CAs in different organizations, you have a far lower risk of seeing all the CAs being compromised at the same time, thus limiting the impact of a CA being compromised.

Note that it doesn't mean a full decentralization, but rather a set of CAs (5 or 10) independent of each other and providing a service as conviniant as Let's Encrypt.

As a side note, an idea a colleague of mine suggested to extend and better the security model of CAs/certificate would be the ability to have a certificate signed by several CAs. Let's say you are a bank or a security sensitive website, you could have your certificate signed by 4 or 5 CAs, and then, you could publish a policy, for example in a TXT DNS record, stating that you need at least 2 or 3 valid CA signatures. This way 1) your certificate doesn't need to be renewed in emergency if its CA is compromised, 2) if a CA is compromised (without people noticing), it reduces the overall impact as an attacker would have to in fact compromised several CAs to actually exploit this (MiM or impersonating websites).

What exactly happens if a CA is compromised (private keys stolen etc)? Wouldn't existing certificates before the compromise date still be valid?

That's precisely the benefit of requiring a multitude of CA signatures -- no single compromise is capable of having a catastrophic impact.

If a CA is compromised critically (private key stolen), then it's removed from the set of trusted CAs you can find in browsers or at OS level (ex: ca-certificates package on Ubuntu/Debian), which in turn makes all the certificates the CA has signed invalid.

With multiple signatures, at least, your certificate is still valid as it has at least another valid CA signature.

Also, right now, if one CA is compromised and if this goes unnoticed, the effect is a bit catastrophic as it's possible to create valid certificates for any domain. With multiple CA signatures in conjunction with a security policy mechanism stating how many of these signatures must be valid, you mitigate this issue as it would require several CAs to be compromised and controlled by the same actor to issue valid certificates.

Let's Encrypt goes down, certs can't be renewed, people can't access websites securely (or at all if HSTS was used).

Good practice says that you should be renewing your certs when they have about 10% of their lifetime left, just in case this exact thing happens with whoever your provider might be.

It's unlikely they would be down for so long that certs would actually expire.

I don't think a percentage is the best way to think about it. There is a lot of variability in lifetimes and the time it takes to resolve issues is not related to the lifetime of the cert.

Just pick a discrete number of days before expiration such that you have a comfortable amount of time to deal with issues.

We (Let's Encrypt) recommend renewing with 30 days left, so every 60 days. If your system is automated like we recommend that shouldn't be burdensome, no reason to do it less often than that.

Also, Nagios/Icinga has a handy certificate checker in check_http. If that is a bit too much then logwatch the log and notify on the box itself.

For what it’s worth, I’ve run into some issues with this guidance from you guys as I’ve been building out a private CA with ACME support. A lot of ACME clients have hard coded renewal at 30 days prior to expiration, which makes them pretty worthless for managing short-lived private certificates. Using a percentage might not encode a fixed SLA very well, but as a default it does accommodate various lifetimes well.

I can see pros/cons either way, just thought you might be interested in this feedback.

The recommended way to use LE is to run the renew command daily and it will do nothing until it finds a cert 1 month or more old. That way you have 2 months to solve an issue.

What happens if their private key gets exposed? A third of the internet being suddenly insecure is a really scary prospect. If everything is automated, a lot of smaller sites may not notice until the certificate expires, or even for some time after that.

Having more options means less fallout if a CA gets compromised.

You may be conflating HSTS with public key pinning. HSTS doesn't care which cert provider you use. CAA and HPKP do. If LE go away or get untrusted, you can get certs from another CA, albeit not free in most cases.

So if Let's Encrypt has a problem, like say their OCSP server is serving errors[1] then the entire Internet is not affected.

https://community.letsencrypt.org/t/may-19-2017-ocsp-and-iss...

Improved security. So many sites are trusting Let's Encrypt and have cron jobs set to refresh data from them. If Let's encrypt were comprised or went offline, they are now a huge single-point-of-failure (or worse, single-point-of-exploit?) for all these domains. It's become a kind of monoculture. A more diverse ecosystem of offerings would be resilient to any single attack or failure.

On the flip side, more certificate authorities (who, remember, also have the ability to delegate intermediate authorities) also means more attack surface, because except in the case of key pinning (which is rare to my knowledge) any malicious authority or compromised authority's certs could be used to effectively intercept web TLS traffic. If let's encrypt was the only authority, yes that would be bad in many ways (and i'm not arguing for that) but it would mean less authorities to worry about. Anyone remember the bluecoat scandal? https://www.vice.com/en_us/article/78kkwd/a-controversial-su...

How would adding additional CAs improve security? By the very nature of the CA trust system, each CA is itself a single-point-of-failure/exploit (though certificate pinning and other measures improve this somewhat).

Letsencrypt doesnt issue certs to Iran, Syria, Cuba, Sudan et al.

That's due to US sanctions.

Right, that's another reason it would be good to have non-US competition.

It's not LE's fault or anything they can do about, but there's plenty of reasons to have alternative options.

Sure, but it would be reasonable for an outfit to (seek funding for) a CA that isn't subject to US sanction rules.

Of course there's a question of where you should put such a thing. Even Russians apparently don't find the idea of a Russian CA trustworthy (they expect that Putin would have his thumb on it, and who am I to argue?), a European CA is certainly not free of American influence, so where would this alternative be based? I don't have a good answer.

Start a LetTheRestOfUsEncrypt.org based in a different country whose government isn't so full of themselves?

Or better yet, is there a way to start a decentralized organization itself so that no jurisdiction has absolute power over it?

How are you going to trust that decentralized org? Is it just voting? Can we all vote to revoke anyone's cert at any time for no reason? What happens when someone performs a 51% attack and takes over google.com's cert?

CAs exist solely because you CAN trust them, otherwise what's the point? We'd just have every site self-sign and let the users choose who to trust.

> CAs exist solely because you CAN trust them, otherwise what's the point?

That's the idea, but in practice, I don't really trust the vast majority of them.

My thinking was that it would be similar to a GPG trust network.

We’ve seen nearly 30 years of web-of-trust failure and yet you still think it’s a workable idea?

As far as I am aware, the only organizations that aren't under the jurisdiction of any nation state or authority are those sponsored by/derived from the United Nations.

Yes we do. On what basis did you make that statement?

We comply with U.S. sanctions by not issuing to entities on the SDN list, but that doesn't prevent us from serving the vast majority of people in those countries.

How do you know if someone is on the list?

When I registered my domain I got WHOIS protection and then LE just made sure I owned the domain. There was no asking about who I am or where I reside or what lists I might be on.

You can search the list here:

https://www.treasury.gov/resource-center/sanctions/sdn-list/...

Some entries have specific domains associated with them, but we are obligated to not serve any domain directly associated with (i.e. controlled by) an SDN entity, not just those listed.

If we become aware that we may be serving an entity on the SDN list (often via someone emailing us) we have to conduct an investigation which may result in termination of service.

indeed I misread it. you don't provide certs for the governments of those countries (still a limitation tbh). I got that from this post of one of your employees

https://community.letsencrypt.org/t/certificates-for-us-sanc...

Well that's interesting, so these are political certs?

no, they are legal certs.

> We comply with U.S. sanctions

What are good non-US CAs?

I haven't checked their TOS, but practically there isn't any limitations in getting certificates from Iranian IPs or for ir domains. If there is any problem, it is that browser vendors/root CAs/etc are not willing to trust CAs in those countries.

You mean like Linux and Git, or do you mean like "blockchain brofedora authoritarian lulz"?

They could pull a cloudflare and stop granting certificates to people that are out of moral alignment with them.

Or the government could lean in on them require them to not grant certificates to some foreign institutions. Even worse, they could be forced by NSLs to issue fraudulent certs (CT log verification isn't mandatory yet, is it?)

Reply on news.ycombinator.com