Let's Encrypt: Looking Forward to 2019 | Hacker News Reader

Let's Encrypt: Looking Forward to 2019

letsencrypt.org

408 pointsjaas68 comments

The thing that has always impressed me the most about Let's Encrypt has been Boulder (their CA server). Not for its code quality, but the fact that they have been able to create a fully transparent, open-source CA server that meets the Web PKI and the CA/Browser forum's baseline requirements.

Most of the time in incredibly regulated sectors, most of the products you see are huge, proprietary, and generally crap. It's such a rare treat to see a nice, simple thing that works in such a bureaucratic environment.

It really shows that Let's Encrypt are completely driven by wanting this thing to exist and be amazing, since they will slog through all the baseline requirements to get there. Most other open source initiatives fail when they reach the compliance stage because the work just becomes completely not fun.

Kudos to all the people at Let's Encrypt, and I wish y'all a very happy new year!

I agree, it’s really impressive. Sometimes it’s not only the software that matters, but also things like seeing potential for simplifying bureaucracy.

With that said I have huge amounts of respect for all the people (e.g. at Mozilla) who makes the CA system work.

I wouldn't call Boulder Open Source, but rather Libre as it is under MPL 2.0, a file level copyleft license.

What definitions of open source have any traction that the MPL, any version, is excluded?

Open source as a term was popularized as a way to promote licenses that are not "viral" (aka requires release of modified versions of code). This is why many developers default to the BSD license and similar, despite how it allows others to come along and close up their work, like what Sony did with the PS4.

Let's Encrypt is awesome—it's great to be able to not have to deal with buying and renewing certs, and I think the ease of doing this now is great for securing the Web. It's great to hear that they're spinning out ISRG as a separate organization to do the same thing for other parts of the Internet.

The only thing that worries me about LE is that it's almost too easy. What happens when 90+% of the Web is running certificates from the same issuer? Are there any plans to run alternate free ACME CAs to prevent Let's Encrypt from becoming a single point of failure?

Let's Encrypt is the name of a service, ISRG is the non-profit legal entity that provides the service.

ISRG was created in 2013 to be the legal entity behind the Let's Encrypt service. It's not being "spun out," we just never had a website for the legal entity itself until recently.

>The only thing that worries me about LE is that it's almost too easy. What happens when 90+% of the Web is running certificates from the same issuer? Are there any plans to run alternate free ACME CAs to prevent Let's Encrypt from becoming a single point of failure?

Not that I've given it deep thought, but do you think their core strategy would fundamentally make it easier for a second wave if it ever came to that? Compared to traditional CAs Let's Encrypt is all about automation and rapid expiration, and they've not only built significant open source tools to that effect but also gotten the community used to operating that way. At least at a high level it seems like they had a steeper hill to climb just in terms of being quite different from before, but now that the standards have improved and practices are in place it'd be a lot easier for everyone to simply point at new ACME CAs if LE ever went down, and old certificates would then cycle out rapidly and automatically. Obviously actually establishing a good new CA that would be trusted wouldn't be trivial itself, but it's also more abstracted from the end user then before. And there are major entities that could step up in an emergency.

I may be missing something here, but at least my feeling has been that LE is not merely providing a good service for now, but permanently improving the entire ecosystem in a lasting way and that if root forbid a meteor hit them or something it'd still be possible to recover better then before.

Absolutely. Not only has it encouraged other capable companies to start their own CAs, switching between CAs will pretty much be a endpoint configuration. Think that’s already the case with the test vs production server, no reason it can’t point anywhere else.

> What happens when 90+% of the Web is running certificates from the same issuer?

It looks like a bad thing, but the TLS CAs are organized in such a way that any rogue issuer can compromise any certificate. This way, consolidation only reduces the risks.

Consolidation reduces the risk of a CA issuing a rogue certificate, probably. It increases the risk that the rogue CA is the CA that issued your certificates; in the worst case of swift revocation of the CA by browsers, that's not a fun place to be as a customer. Especially if you've done something like CA pinning (in or out of browser context)

”Are there any plans to run alternate free ACME CAs to prevent Let's Encrypt from becoming a single point of failure?”

This is an interesting question. Let’s Encrypt is built on openness and open source software, so it’s possible to ”clone” their service. However, it would require some funds to do so. (According to the article, they now operate on $3.6M/year.) So I can’t see that happening soon, not as long as Let’s Encrypt run their service in a trustworthy manner. But perhaps some entity would spin up a niched version. E.g. if a country would launch it’s own LE service for their citizens and domestic companies and organizations.

[Edited again regarding funds required.]

We pride ourselves on being an efficient organization. In 2019 Let’s Encrypt will secure a massive portion of the Web with a budget of only $3.6M. We believe this represents an incredible value and that contributing to Let’s Encrypt is one of the most effective ways to help create a more secure and privacy-respecting Web.

That is incredible!

A focused non-profit attacking a real problem can be extremely effective. I hope the rich tech people on HN strongly consider building or donating significant amounts to tech non-profits and open source. Certainly this is more impactful than another advertising network investment.

The concern I have is that these vital non-profits (one might say critical infrastructure, depending on the org) have to go hat in hand to the community each and every year for their operating funds, whereas if they had an endowment or some other investment account backing them, they'd be able to survive in perpetuity.

At a 4% withdrawal rate, Let's Encrypt would need $100 million invested to not need to ask for funds in the future (assuming they don't drastically increase their operating expenses).

Governance and oversight is mandatory though; Wikipedia has net assets almost near $113 million [1] and requires less than 600 servers to operate (plus colo costs, connectivity, technical staff, etc). On the other end of the spectrum, OpenStreetMap costs $118k a year to operate [2].

[1] https://en.wikipedia.org/wiki/Wikimedia_Foundation

[2] https://twitter.com/floledermann/status/1057254329290235907

LE cannot die, much like Wikipedia. Google et al would buy them before that happens.

Transferring ownership or control of a root CA requires assent from the trust stores.

That's one (of several) reasons WoSign / StartCom was distrusted, they tried very hard to conceal the change in ownership of StartCom.

Assent might well be given, but it isn't automatic. This came up for Symantec selling their CA business, and also for other CA outfits doing internal reorganisations which wanted to be clear that these were paper exercises (e.g. for branding) and had no effect on which people controlled the CA in practice.

In the specific case of Google acquiring Let’s Encrypt, the fact that they control the majority of browser share means that it will get added to the Chrome trust list, and everybody else will have to go along.

There is not really a "Chrome Trust List". The Chrome browser does have Google-specific policies, but it doesn't use a Google trust store, it uses the OS supplied trust store, e.g. on Windows it consumes SChannel's Trust Store and the macOS version of Chrome uses the macOS Trust Store.

On a Google Android device, such as a Pixel, Google are responsible for the OS trust store, as they build the entire OS, but in practice it's basically the Mozilla trust store.

To the extent that we can say "Everybody else will have to go along" with anything when it comes to the trust roots, I'd suggest it's whatever Mozilla, a public charity, chooses to do. A brutally frank person might suggest that for-profit trust stores (all the big ones except Mozilla are for-profits) see considerable value in having unwelcome but necessary decisions made officially by somebody else before they "reluctantly" go along with them.

Also, Google is a very big company, the people who work on Google's Certificate Authority, the people who work on Chrome, and the people who co-operate with Mozilla are three separate groups at Google.

Sounds a technicality, what I know is chrome and Firefox independently distrusted Symantec. Google didn’t have to wait for Mozilla

Trusting and distrusting are not the same.

> whereas if they had an endowment or some other investment account backing them, they'd be able to survive in perpetuity

There's a strong argument that entities like Wikipedia having to constantly go back to the community trough to survive, assists in keeping them well behaved. I prefer to keep Wikipedia begging and slightly desperate, rather than obese, detached, entitled, crusty and overly bureaucratic.

The user community that funds them can kill them off through funding deprivation in a short amount of time if Wikipedia decided to become a scumbag. Their annual cost to operate has perpetually increased, it's closing in on $100 million now (three or four more fiscal years at the rate they've been increasing it). They wouldn't survive long without the donations flowing in every year. They could plausibly make a large deal with eg Google on advertising if the user funding dried up due to bad behavior, however that would just be more likely to accelerate their implosion.

It's dangerous to the mission of a charity / non-profit to hand it a position of certain financial perpetuity. All organizations are very much susceptible to bureaucratic creep and wandering off mission in such situations. It's why many of the great philanthropists (Buffett, Gates and Carnegie to name a few) have sought to expend their fortunes relatively rapidly in charity rather than have the charitable trove exist in perpetuity via a perma-institution for parasites to attach to over many decades.

This is a great comment and a really valuable perspective. I have to note, however, that financially precarious nonprofits can also veer off in bad directions, or become ossified, or whatever, and the result is they fail outright.

A benefit to Wikipedia’s situation is they go directly to their user base for funds. When nonprofits are financially precarious or dependent and rely on small numbers of moneyed donors, they can just as easily go off mission and/or become corrupted.

> When nonprofits are financially precarious or dependent and rely on small numbers of moneyed donors, they can just as easily go off mission and/or become corrupted.

What you're describing is exactly the situation that Mozilla has been in for the last decade or so, and I always feel a little uncomfortable about it. The vast majority of their income is from search deals with one or two vendors.

This was the Buddha's own thinking when he established his order of monks. Sadly, it has not weathered the last couple thousand years in such grace, as many East Asian Buddhist monasteries have become thoroughly corrupt, with monks misappropriating funds.

Perhaps nothing can preserve institutions from ossifying than date-determined termination.

Yes it is very impressive and shows what can be done with not much.

> The [BGP hijacking] solution we intend to deploy in 2019 is multi-perspective validation, in which we will check from multiple network perspectives (distinct Autonomous Systems).

This is really exciting. The CloudFlare BGP hijack and subsequent attack of myetherwallet.com could have been much more successful if they had also been able to get a valid certificate. Having this multi perspective feature would make it even harder to get a valid cert during a BGP hack. Of course those falsely attained certs would still be logged publicly in a certificate transparency log- but better the cert never gets created to start with.

> We had planned to add ECDSA root and intermediate certificates in 2018 but other priorities ultimately took precedence.

I was particularly looking forward to ECDSA. Not for any real reasons other then I want to try it out. I currently have their 4096 bit RSA cert on a raspberry pi and the SSL negotiation is particularly slow according to Newrelic. Im curious to see how EDSA performs on a raspberry pi.

You would get a significant speed-up just going to 2048 bits RSA. EC would be even faster but slightly more work. You don't need 4096, unless somehow your Raspberry Pi is the target for a powerful adversary and you don't rotate the keys (like a CA). The Let's Encrypt defaults auto-rotate keys on each renewal.

Note however that you can go to EC today. Your device doesn't care about the CA keys, so those still being 4096 bit RSA makes no major difference to you.

> You don't need 4096, unless somehow your Raspberry Pi is the target for a powerful adversary and you don't rotate the keys (like a CA).

See https://github.com/certbot/certbot/issues/2080 for some long debate and my most recent thinking about this. (I predict some discussion about this at Real World Cryptography in January, if only because I'm likely to ask some real cryptographers for their opinions there.)

> Your device doesn't care about the CA keys, so those still being 4096 bit RSA makes no major difference to you.

Your device does care about the CA keys, because it has to validate the certificate chain. But the Let's Encrypt CA uses a 2048-bit RSA key, regardless of the size of the key you're using.

Yes, this is why I haven’t bothered with the current EDCSA support. As for the 4096 bit cert on my Raspberry Pi- this is more fun interest then actual concern someone is trying to break my static site

The client cares but the server needn't, and since they're saying it needs a certificate from Lets Encrypt I presumed it's a server.

For a server the certificates are just a pile of bits to be transmitted. Server software could be introspective but in general it isn't, e.g. it doesn't do AIA chasing.

But you're correct that I had misremembered the root as being 4096 bit and it's actually 2048.

One thing that massively sped up serving content on my RPi was precompressing everything static and disabling on-the-fly compression.

I'd also be more exited about getting EdDSA leaf certificates than ECDSA.

”We are also planning to introduce a Certificate Transparency (CT) log in 2019. All certificate authorities like Let’s Encrypt are required to submit certificates to CT logs but there are not enough stable logs in the ecosystem. As such, we are moving forward with plans to run a log which all CAs will be able to submit to.”

I’m glad to see that they’re prioritizing this. Not a giant leap but still an important step for ensuring the stability of the CT system and the trustworthiness of the CA system.

I absolutely adore what Let's Encrypt has done for the Web, and I proudly wear the hoodie they gave my company for our sponsorship. It's amazing what a company of 11(?) people can do, most of which probably don't even do any development.

However, I really think that they need some (free) competition --- their market domination is becoming a little extreme. Someone else offering free certs via the ACME protocol would be nice

I very recently learned that BuyPass (a paid CA) now offers a version of their DV product via ACME

https://www.buypass.com/ssl/products/acme

The way that I learned about this is that acme.sh (the awesome ACME client by Neil Pang) announced support for BuyPass alongside Let's Encrypt:

https://github.com/Neilpang/acme.sh/wiki/BuyPass.com-CA

Obviously this is really great in every respect, including a potential opportunity for finding compatibility bugs with ACME implementations.

So perhaps what you were hoping for has already happened!

(Edit: also, thanks for your support for Let's Encrypt!)

(Further edit: apparently the BuyPass ACME certs are valid for 180 days, as against Let's Encrypt's 90 days, but only let you list approximately one domain per cert, as against Let's Encrypt's 100 domains per cert. https://community.letsencrypt.org/t/acme-sh-supports-tls-alp... It's still awesome to see more options for ACME support and definitely makes it more credible that it wouldn't be as serious a problem if Let's Encrypt went away some day for some reason.)

Those statistics are unbelievable! That is a huge portion of the internet that went to https.

If anyone from LetsEncrypt is reading, I just want to say thanks. Your tools have enabled me to quickly and easily set up encryption for several domains and sub domains.

And your documentation is great. Being able to select an operating system then a server and receiving crystal clear instructions on how to proceed is fantastic for a non devops guy like me.

Moving forward easily and painlessly will absolutely never be underappreciated on my end. Thank you!

Encryption related things I'd like to see become easier (not free):

* Code signing, particularly driver signing on Windows (thanks for making this very difficult for open source, Microsoft)

* Script signing, a-la Powershell AllSigned mode (even though it's caused me pain in the past and needs better IDE support)

Not only they are free of charge, but Let's Encrypt certificates are some of the most technically featured ones too.

- Embedded SCTs, so you don't have to worry about certificate transparency.

- Must-stable flag support.

- ECDSA leaf certificates.

Digicert is doing an excellent job too, although expensive, trying to push the tech forward with new flags such as signed HTTP exchange, but LE is not only free, but they are _better_ in many ways.

Just in case anyone else wonders, SCT = Signed Certificate Timestamp.

"Must-staple"

Thanks, yep I should've double checked for typos.

Point to note, VPS service like Bluehost have started providing Let's Encrypt SSL certs to all domains by default requiring no further effort. I hope others such as Hostgator, InMotion Hosting etc. follow the suit.

This is tracked in a frequently updated post at

https://community.letsencrypt.org/t/web-hosting-who-support-...

(That post doesn't track support on VPS plans because if you have root, you can run Certbot, Caddy, acme.sh, or other options to get the certificates yourself.)

Supposedly CPanel has LE support nowadays, so most companies should get it when they upgrade.

Yes, the user can upload a certificate via CPANEL manually using a service such as Zero SSL; but bluehost does those automatically & there's no action needed for updating the certificate every 3 months (as is the case when done via cpanel) in VPS.

No, I'm not talking about manually uploading a cert; I'm talking about AutoSSL, their feature that automatically requests and installs an LE cert: https://blog.cpanel.com/announcing-cpanel-whms-official-lets...

Good to know, thanks.

Let's Encrypt is one of the best things that has happened to the Web in the last few years. Everyone wants (and needs) SSL/TLS, and there was no reason for companies to be charging so much for the service. Kudos to the authors and maintainers of something that saves so many people time and money each year.

> The feature we’re most excited about is multi-perspective validation. Currently, when a subscriber requests a certificate, we validate domain control from a single network perspective. This is standard practice for CAs.

I wonder how many other CAs do this as well? The third sentence suggests few.

The third sentence means it is standard practice to validate from only a single network perspective today.

I have heard we would not be the first CA to do multi-perspective validation, but as far as I know we would be the only CA of significant size doing it. I do not know of other CAs doing it today, but we have not done an exhaustive survey.

Also, architecture and implementation details matter for this kind of feature. How many perspectives, what networks... We are lucky to be working with a great group from Princeton that has been helping us design our implementation.

Lets encrypt should get involved and get the starttls-everywhere project happening like they did for the web.

https://starttls-everywhere.org/

Other than SSL are there any other parts of websites and web presence that are relatively expensive now and could be done pro bono non profit? Maybe a TLD domain that would be absolutely free??

> Maybe a TLD domain that would be absolutely free?

Can't easily do this and prevent squatting without onerous identity requirements.

"Just put it on the blockchain"

Well, .tk[0] is a free TLD, but it’s not specifically non-profit.

[0]: http://www.dot.tk

They tend to hijack domains when they get popular.

I remember punk bands/fanzines using .tk back in the early 00s. I’m quite surprised they’re still around :)

Namecoin's .bit namespace is a bit like this, but since it requires custom software or DNS servers to access them, it's use is unfortunately limited for now.

What happened in June/July? It looks like they had 50% growth in those two months alone.

If I had to guess, it's probably related to Chrome marking HTTP sites as "Not Secure" in July 2018. A lot of sites were probably scrambling to get certificates before Chrome 68 was released.

https://www.neowin.net/news/chrome-68-will-mark-http-website...

In May GitHub pages started rolling out LetsEncrypt support for custom domains: https://blog.github.com/2018-05-01-github-pages-custom-domai...

> multi-perspective validation

This one caught me by surprise earlier in the year. When I was building some new infrastructure to support HTTP-01 validations in a multi-region deployment (routed using least-latency), one day I suddenly started seeing what looked like multiple validation requests hitting my EU deployment. Had me very confused for a few minutes, first thinking my logging infrastructure was suddenly very broken, or I had somehow configured my load balancers to cross regions, except the requests were coming from many different public addresses.

After some more minutes of digging and I found out about multi-perspective validation on the staging environment.

Anyway, good idea. And it seems to work from what I've seen. It seems just a surprise when it turned on while I was literally working on code/infrastructure to handle validations.

Getting a free wildcard from them has made my whole setup so much nicer and more dynamic. I absolutely love it.

Let’s encrypt is one of the best things to happen to the web recently. Great stats.

Let's Encrypt and certbot have made my sysadmin life so much easier by allowing me to manage certificates within the terminal and without having to deal with annoying CA UIs that try to sell you tons of stuff you don't really need.

And all that for free!

If you are a regular user, please consider donating to the cause: https://letsencrypt.org/donate/ You can make a one-time donation or set up a recurring one.

$3.6m budget, I love this. For the impact they've made, this an extremely efficient. If a government program tried to do the same thing we'd be talking billions.

great service to public

Reply on news.ycombinator.com