A Year-End Letter from our Executive Director
letsencrypt.org
letsencrypt.org
I'm just really grateful for the service, and glad to see the Prossimo work continuing as well.
(On a tangential note, I suspect the way Let's Encrypt makes me feel is the thing that people wish Mozilla still had whenever there is a Firefox thread that turns bitter. Like a breathe of fresh air on a cynical internet.)
I get that's designed to protect themselves for the long term and it sounds like they've made it so they don't need my money for now, at least not at the expense of other projects that don't have such cash reserves like Let's Encrypt.
After I read your comment, I thought they had 10x annual expenses or something but really they have 18 months of runway. That's not that long IMO.
https://www.washingtonpost.com/news/the-intersect/wp/2015/12...
And that are outdated numbers from 2015.
2021 report:
$153m dollars in donations spent on $67m in salaries, $10m in grants (surprisingly low, in 2020 it was $20m), $2m in hosting and like $10-20m in other professional expenses.
Net assets at the end of 2021 now at $231 mio.
https://upload.wikimedia.org/wikipedia/foundation/1/1e/Wikim...
If we only looked at costs related to hosting the website they have almost 100 years. They got total assets of 191 millions, and the website hosting costs are 2.4 millions each year. 55 millions each year goes to wages (up from 46 millions previous year).
https://wikimediafoundation.org/about/annualreport/2020-annu...
Charities have a common guideline that a maximum of 25% of donations is allowed to go to operations of the charity and minimum of 75% must go to the purpose of the charity. That mean if you donate to cancer research, 75% should go to cancer research and a maximum 25% to operational costs of the charity. I personally find 25% to still be too high.
When Wikipedia is asking for donations to keep the servers running then people expect more than 2% of the donations will go to that purpose. If they asked for donations to operate and pay wages to the foundation then they a perfectly free to do so and people wouldn't call them out as much when 49% is taken out as wages.
This person is advertising their consideration of donating to LE instead of Wikipedia, and by doing so encouraging others to consider the same. That’s allllll that’s happening here.
If you want a web-related alternative also consider archive.org (and their Wayback Machine).
Side note: I was expecting this CEO letter to end with layoffs.
I'm still old school but can set this up all using the letsencrypt command line utilities that configure everything for me.
Oh, and whatever the hell GoDaddy's intermediate chain certificate was.
Re: Godaddy, I was using their "EV" (Extended Validation) cert which added a company name indicator in the address bar. I then learned that it's unwise to bring up security when someone isn't thinking about it because it puts them on undue alert. A couple years ago the browsers have done away with that EV badge altogether.
Customers were seeing the prominent green text and assuming a heightened level of security and trust.
Legal names are also not unique, and this loophole could be used for phishing.
Instead, what browsers did was promote SSL as a default (regardless of certificate type) and point out HTTP connections as insecure.
Actually Apache recently introduced mod_md, which allows provisioning certificates from Let's Encrypt directly (or anything else that supports ACME): https://httpd.apache.org/docs/2.4/mod/mod_md.html
Because of this, you no longer need external software like certbot for Apache (though it's good software regardless: https://certbot.eff.org/pages/about), so in that regard Apache is a bit more like Caddy (another good web server: https://caddyserver.com/), rather than like Nginx.
I wrote about it and other configurations of Apache on my blog a while back: https://blog.kronis.dev/tutorials/how-and-why-to-use-apache-... Since, I've actually moved most of my personal workloads from Nginx/Caddy over to Apache, because at my scale the web server isn't the bottleneck and if you disable .htaccess to limit disk I/O it's pretty decent, in addition to lots of different modules.
Either way, working a bit more with certificates, even with tools that simplify the process, is a nice way to understand everything a bit better, like running your own CA: https://blog.kronis.dev/tutorials/lets-run-our-own-ca I still have lots to learn, at least when I want to get pretty particular about mTLS and what some client certificates can or cannot be used for.
Of course, any software that actually helps you get things done, is user friendly and has ample (correct) tutorials available is a good option in my book, regardless of what your particular choice ends up being! Let's Encrypt as a whole is an absolute life saver, though! Edit: even if it feels like a looming massive single point of failure with few viable alternatives sometimes.
That said, I like its configuration format a bit more than Apache and there's just way less ceremony around it in those cases where it's suitable for any of your projects - you just install it and run it, with any config you might need typically in a single file.
With Apache, you find yourself needing to think a little bit more about what modules you have installed and enabled, although there are actually plenty of those out there, for most things you might want to do (e.g. an authentication gateway or something to make it act as a simple web application firewall).
Best I can tell from their 2022 Annual Report, they operate pretty lean...22 employees and 10 board members. (see page 44)
https://www.abetterinternet.org/documents/2022-ISRG-Annual-R...
Let’s Encrypt only gets rid of the latter, and given that fraudsters able to spoof the former can probably spare the $10 for the latter, I‘d argue that this is a good thing.
All of that noise is gone now. That makes the internet much safer.
Not sure it's a downside/upside thing. It might shed light on the types of people who get hired at facebook.
Pick the brain of any accomplished engineer, and you'll quickly see that the technical knowledge they use to write code on a day to day basis is only the tip of the iceberg.
It's not reasonable to expect everyone to know everything all the time, but I don't agree people should be aspiring to just know the bare minimum either. Mediocrity is like gravity: if you don't (at least occasionally) aim higher, your trajectory will be lower than you want.
You don't know why they haven't taken the time to learn. At least they know enough to know they need an SSL cert. Should I not buckle up in a car if I don't understand the mechanics of how the buckle snaps together?
I don't understand why you're harping on this person for this.
"frankly I don't care to know the details"
I take issue with that statement not the person. The statement was honest and matter of fact.
Few know how SSLs work, few have time or opportunity or even desire to learn it. Not 'wanting' to understand the details goes against what I would expect. A programmer tries to/needs to understand how the world works. Not wanting to understand the entire stack is a new concept to me.
Then I'd suggest that your experience about the world, and about people in general, is severely lacking.
There aren't enough hours in a day or years in a life to learn everything, so we have to be selective.
Do you know how CPUs work, down to the various functional units and pipeline stages and how they work together? Can you explain to me how transistors work on an electrochemical level? Can you explain how silicon wafers are fabricated? Hell, I took those classes in college as a part of my EE degree, and I can't really remember it well enough to explain without cheating and looking at Wikipedia. (And even then...)
And guess what? That's just fine. I have no need or desire to dive that deeply back into that stuff.
Why should the minutiae around TLS certs be any different? I do know how TLS cert provisioning works, and to be honest, it's boring and tedious. And I do it so infrequently that I have to look up a tutorial every time I do it. It's just not worth keeping in my head. If I could use LE for everything, and never try to remember the right `openssl req` command ever again, that would be great.
> A programmer tries to/needs to understand how the world works.
No, a programmer is someone who solves problems with code. How they do it, and what types of knowledge they pursue, runs the entire gamut of possibilities.
Bottom line: knowing technical minutiae doesn't make you cool or special or better than other people. It just makes you someone who's interested in that stuff, or someone who needs to understand it as a part of work they do. Let's not elevate it to something it's not.
People may think they are Cool or special for millions of reasons (like not knowing what ssl is for example).
I could absolutely be wrong about that reasoning, though, but that's my point - we don't know why, so why assume a negative and then lean into that?
I mean, c'mon, it takes quite a bit of arrogance to condemn someone for some little facet of their life when you know next to nothing about them.
Technology shouldn't be a blackbox and shouldn't be celebrated as such.
General public does not differentiate between the SSL certificate validation level.
Let's Encrypt provides domain validation certificates, which only validates that one owns the domain in question.
There is another level - Organization Validation SSL certificates, which involves manual checking that this is the legal entity it claims to be. I would expect the financial institutions to use this kind of certificates to avoid phishing, but sadly I've seen some of them use Let's Encrypt.
I realize an org itself won’t fancy ponder its inevitable deviation from today’s course at some point in the future, but the netizens probably should…
(Sorry for sounding gloomy. :)
If you mean is it dangerous for one organization to have a root CA that if it went entirely rogue could theoretically be used to MITM peoples' traffic, that is definitely a concern, and why a process exists for removing a root CA from the mozilla, chrome, microsoft etc root CA trust stores.
Sure it's annoying to change to a different service, but they don't have access to any server secrets and all their certificates are logged.
If they disappear or change something, it will effectively shut down a lot of sites that does not have access to someone knowing how to update to a new cert after three months. Sure, the page will work but most browsers will block the users to get to it or require them to click things with scary messages on them.
Holding the key also means they start your engine for you.
Sometimes some things catch on and others don't.
DANE relies on the DNS being end-to-end secure, which all boils down to the root being secure. It's extremely centralized in a way that is just diammetrally opposed to how the Internet is designed.
The other big reason DANE isn't deployed, even as a trial balloon in browsers for the rare cases where DANE records actually exist, is that the Internet is full of middleboxes (caches and rando routers) that block DNSSEC, or really any atypical DNS response at all. The browsers tried rolling out DANE, and it caused reliability problems. DANE advocates tried to work around this with stapled DANE records as a TLS extension, which failed due to security concerns, and is now a dead letter.
(There is an obvious chicken-egg thing happening between these first two reasons that strongly suggests this will remain a stable equilibrium.)
The best reason DANE isn't deployed is that it vests keying authority with organizations that can't be revoked. World governments control most of the most important TLDs, and most of those have demonstrated repeatedly that they will alter the DNS for their own policy goals. Google can dis-trust CAs that act up, and in fact they did that a few years ago for one of the largest CAs in the world. Google can't dis-trust .COM. Mozilla can realistically threaten to dis-trust any CA that doesn't implement Certificate Transparency, but nobody can threaten a TLD owner if they don't enroll in a (fictitious) DANE Transparency program --- part of the reason there is no such program.
Speaking of TLDs, there are still some TLDs that don't support DNSSEC at all, meaning that some that do want to use DNSSEC/DANE (usually for certificate pinning for MX systems) have migrated to TLDs that do. Also IIRC DANE can be used in a "verify that this is the key but also checked if it's signed by a trustworthy CA", but at this point why bother?
There are services which monitor those logs to alert owners and it makes it easier for researchers to piece together what happened retroactively, as we saw recently with the TrustCor affair where CT logs were useful for determining what certificates that CA had been issuing.
With http-01, ownership has to be proven every time a new cert is issued.
> Such an attacker would likely have also stolen the TLS private key, but that only stays valid for 90 days
That doesn't have to be the case; the private key can be valid for as long as someone wants it to be, unrelated to the validation period of the cert that is issued. Yes, it does look like certbot generates a new keypair for every renewal, but in a world where we were putting a pubkey in a DNS record, the private key would certainly have a much longer validity, as otherwise there'd be no point to doing it this way in the first place.
If anything, as far as I'm concerned, DNS-based challenges are a stronger proof that I own the domain as it requires access to the nameserver. HTTP-based challenges just prove that I have access to a computer pointed to by a DNS record which is far easier to get wrong. This is why wildcard domains cannot be issued to HTTP challenges, just because I can serve a file on a subdomain doesn't mean I own the parent domain.
But I agree, using a key-based DNS challenge would be a new feature. It was discussed before but at the time LE devs didn't come to a consensus with how to move it forwards.
In addition, the new work mentioned in this letter is ARI, or ACME Renewal Info, which is not directly tied to any of the aforementioned renewal methods.
Although it does require an additional NS which is an additional maintenance overhead - that is preferable to leaving automated services sitting around with write access to important domains. At least until I can stop regularly writing DNS records.
Not that it isn't good, but "why talk about it in a letsencrypt end of year message" -is this the wider "we" at play, or was there something specific I missed?
otherwise great news that LE is still doing well as an org