I love them. I'm not really sure how SSL works or what it is (and frankly I don't care to know the details) but with 2 commands I can get that magical lock on any website. I'm glad they're doing well. Thank you!
As someone that supports Let's Encrypt's efforts and playing devil's advocate, I imagine a downside is that the bar is lowered and nefarious websites can easily get SSL-equipped channels compared to the high paywall of prior.
Commercial CAs verify exactly two things: Administrative control over a domain name and a working credit card number.
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.
It meant a paper trail via CC payments (though fraudsters were likely to use stolen CCs, and they probably needed a CC to buy the domain name in the first place). But yeah it's basically not fundamentally different.
My guess is a misunderstanding of how easy it is to get a credit card to make a payment. This hasn't gotten any easier, so there truly is no downside at this point, unless people automatically think a SSL means a site is trustworthy. I think that's just education, and is likely to come into public consciousness the longer secure sites are pushed as the default.
Before Let's Encrypt there were all kinds of bullshit CAs that would distribute secure sites "seals", and lie all over the internet on how those meant anything.
All of that noise is gone now. That makes the internet much safer.
Ok I get not wanting to pick on the guy, but is that really reasonable? Engineering is about solving problems by designing/implementing systems. The more you know about the system(s) you're working with, the better the solutions you can build. Even if you're "just" working at a high level and maximally specialized to a single niche, not knowing how the underlying parts work will really limit you.
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.
Right obviously very few people will be deep experts on the nitty gritty details of any particular thing, but it's weird to work with computers and not have a broad high-level understanding of something as crucial as TLS and PKI.
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.
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.
> 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.
Are programmers losing that childhood curiosity for how things work? Do programmers even value that anymore? Should that be the filter employers use to select candidates vs leetcode?
People may think they are Cool or special for millions of reasons (like not knowing what ssl is for example).
Who says they've lost the curiosity? What if all of their programming effort and energy is put into whatever the website is for? Why should they shift their focus over to learning all about SSL when that's not the point of whatever the project is and it will suck up too much time?
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?
Or maybe we should just avoid judging people based on what they do and don't think is worth their time learning, especially when all we know about them is a previous job title and a short message on an internet message board?
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.
I think there are a lot of perfectly good programmers who work at the level of the web stack, but couldn't set up a web server with TLS to save their life. There's nothing wrong with that, and suggesting that there is, is just a form of technology elitism and gatekeeping.
This isn't about being able to. I've love to setup machine learning but lack the understanding. It's about taking pride in not having to learn.. taking pride in not having to understand how things work.
Technology shouldn't be a blackbox and shouldn't be celebrated as such.
Downside existed before Let's Encrypt, it just got amplified with it.
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.
Browsers don't differentiate between the SSL certificate validation level. Because it has been shown that the higher validation levels aren't actually significantly more secure, so the distinction is pointless.
I don't think this is an issue with LE or the implementation. Maybe we need different policies for such organizations, but this is for sure not a LE issue
It saves me from the implementation details, this way I don't need to wear another engineer/sysadmin hat. I think the website content is more important than the SSL implementation!
Indeed! It's how security should work, and should be the default dual-goal of any piece of security software: provide as much security as possible to as many people as possible.
I should hope HN hashes our passwords, instead of encrypting them. And for encrypted data I would expect them to use symmetric key encryption, rather than certificates with RSA or another form of public key cryptography.
Your post contains some very basic misconceptions. This is going to sound harsh, but I would recommend not putting too much stock in your own opinions on security, and instead to trust the experts.
Not harsh at all. I understand I am no security expert, bores the heck out of me. Sadly, you shouldn't trust the "experts" to be if that's LetsEncrypt. No one can be trusted apart from yourself when implementing security.
If LE is ran with the following companies, "Electronic Frontier Foundation; Mozilla Foundation; University of Michigan; Akamai Technologies; Cisco Systems"
What makes them all trade worthy, especially when they're all American? Especially after the whole Richard Stallman. Mozilla, maybe because they were netscape. I have more than enough experience working within security to know that.
I've seen SysOps leak DB's, Passwords in plaintext.. and I've seen it from the age of where such didn't exist to where companies are now installing X security appliances to safe guard there networks. I'm not newb, from 2004 to now, counted 15 years of System and Network engineer experience. Fair from experienced but well seasoned.
Why isn't HackerNews using LetsEncrypt, Google, Netflix, Amazon, if promoted as a great thing. Is what I want to know.
HN: Pretty sure their relationship with DigiCert predates LE, why change if the current relationship is functional.
Google: Browser Maintainer that runs entire TLDs, doesn't need a third party, it could just decide to trust itself and 60+% of the market follows.
Amazon: Runs a massive chunk of the internet, it's already MitM'd itself and most other things, doesn't really need a third party for Certs but still uses DigiCert which predates LE and they clearly have a working relationship.
Netflix: See Amazon, HN.
You: Barely exist to the infrastructure of the web as people experience it. Maybe you have a static site you don't care to protect from MitM (could add some malicious scripts or whatever but who cares). Maybe you're a tiny service that offers some 50 users something, their plaintext auth probably shouldn't be readable to just anyone along the network path, but they're not paying you for services so you might not wanna spend much money on that service. Use LE.
Also, if you think LE as a company has the ability to take sites with it if it goes down, you don't really understand Web PKI. At most likely within a year to 3 months you'd need to find a new place if their signatures expire. At worst someone could pretend to be you, but still not read that traffic protected by the old cert.
Why so salty about LE? Especially from a "seasoned" SysEng? Didn't it just make your job easier and safer for those with slightly less experience?
> Why so salty about LE? Especially from a "seasoned" SysEng? Didn't it just make your job easier and safer for those with slightly less experience?
Because it's required, I don't know the companies, I can't trust the companies. I just not happy that four companies run the worlds SSL. There should be another technology that caters to such without having to put all the keys in one basket.
> Why so salty about LE? Especially from a "seasoned" SysEng? Didn't it just make your job easier and safer for those with slightly less experience?
Because it's required, I don't know the companies, I can't trust the companies. I just not happy that four companies run the worlds SSL. There should be another technology that caters to such without having to put all the keys in one basket.
> Didn't it just make your job easier and safer for those with slightly less experience?
No. It makes it harder, because your not teaching someone anyone thing you tell them "click here, click that, done"
I believe you get downvotes because you think by analogy rather than by reasoning. Not having that big corporation example doesn't negate Let's Encrypt's value proposition (and the improvement they brought compared with the way things were done before).
Also you're mixing security on data transportation with security of data at rest. Both are important but there are different solutions to each.
So for one, if you're looking for an actual answer, dial it down a few notches. Your post is 18 minutes old as of me writing and you're already boasting about a lack of replies.
Two, you're likely misunderstanding the purpose of SSL and Let's Encrypt. It's not to protect you against the site you're talking to, it's to prevent man in the middle attacks on the way. It ensures you can't walk into a starbucks for an hour and walk away with dozens of facebook logins.
Lastly, the big players don't use Let's Encrypt for reliability and customer service purposes. If you run a blog and your cert screws up, the 3 people visitng your site that week will have to click a few extra buttons to get in.
If you're a microsoft, that can mean thousands if not millions of users hitting this wall they expect not to have, leading to huge costs for customer support and occassionally deeper issues updating certificates. Exactly the same reason Bank of America doesn't use godaddy.com for their domain name.
Before Let's Encrypt, certs cost money from certificate authorities, so not many smaller companies would bother. Now it's streamlined enough that browsers throw scary warnings if you don't have it, which is a massive improvement for everyone using the web.
> Before Let's Encrypt, certs cost money from certificate authorities, so not many smaller companies would bother. Now it's streamlined enough that browsers throw scary warnings if you don't have it, which is a massive improvement for everyone using the web.
But should they? I never had any issues running an internet site before this was required. A blog doesn't need SSL. Why are ISP's not more scrutinized to ensure that MITM doesn't happen? Why is it put upon the admin? My blog from 2005 was never hit with MITM.
> If you're a microsoft, that can mean thousands if not millions of users hitting this wall they expect not to have, leading to huge costs for customer support and occassionally deeper issues updating certificates. Exactly the same reason Bank of America doesn't use godaddy.com for their domain name.
So your saying LE is only worth for small-class sites such as "blogs", which than I above said, Why does a blog need SSL? The only reasoning I had which was valid was that "ISP's inject" and if that's the case why are ISP's allowed to get away with injection?
> Your post is 18 minutes old as of me writing and you're already boasting about a lack of replies.
Folks like to down-vote and never reply. I'm sure I might be "flagged" soon too.
> Two, you're likely misunderstanding the purpose of SSL and Let's Encrypt.
Not at all, SSL is the communications protocol. A encrypted-tunnel example made by HTTPS. Verified by a Certificate if we apply laymans terms. LetsEncrypt issues that certification based on the trusted root installed on your computer and if all valid, the brower throws a green badge. I can easily remove the LE root certificate and any LE encrypted site would be invalid.
> That's not you winning. You made things worse for everyone.
I've made nothing worse for anyone. Those who made it worse for everyone are internet walled gardens and monopolies. If the internet wasn't as corrupted as it now and you deny, telling me Google isn't evil? We would be in a better place with enhancements without the the need for SSL. However not so, evil and mass greed ruined the internet for all since the 80's; heck the 70's.
No, not flame-baiting. Am I not allowed my own view based on my own thoughts? Or am I not allowed free-thought? I'm happy to read everyone's else and take that in. But your denying my own? There's no flame, those opinions are of my own and may not be correct in your eyes but I am still allowed to have.
> Those who made it worse for everyone are internet walled gardens and monopolies.
I'm just talking about this conversation being worse.
> you deny, telling me Google isn't evil?
I didn't say anything about Google.
> No, not flame-baiting. Am I not allowed my own view based on my own thoughts? Or am I not allowed free-thought? I'm happy to read everyone's else and take that in. But your denying my own? There's no flame, those opinions are of my own and may not be correct in your eyes but I am still allowed to have.
You posted "No answers for me? Just what I thought." with the specific intent of annoying people into replying.
> You posted "No answers for me? Just what I thought." with the specific intent of annoying people into replying.
I'll agree to disagree on that, the reason is that folk blindly down-vote. It's infuriating. If I hold opinion A which is incorrect, when opinion B could be correct, I then wouldn't get possibly a corrected perspective. At least it sparks a reaction and sights conversation, regardless if annoyance. It allows myself to express how I feel and why I feel. Rather than the hive-mind mentality that if everyone is doing it, its the right think.
> I'm just talking about this conversation being worse.
How? I expressed my opinion. It may not be right, it may be controversial, you may disagree. Yet your post came off as you should have supreme control, you do have many karma points but that still doesn't dictate. I don't doubt your intelligence, nor interactions, myself I am only 33, still learning the world. For all I know you could be god if you believe in such a thing.
> you deny, telling me Google isn't evil?
I'm was laying my beliefs based on the misunderstanding of your post. I misunderstood how "conversation being worse" it happens. However that again is another controversial opinion that the internet is within a very crippled state, for such pointed out above. Again, you may disagree.
Your entitled to such opinion you believe, I'm disappointed that if you did flag me, or that such a feature blocks because what I laid out wasn't out to be argumentative but as free-thought opinion. Maybe more emotional and cynical of than what it should of been but still. Words are tricky and no one person is an expert.
Putting a TLS cert on your blog also allows visitors to (mostly[0]) hide their traffic and activities from entities that might want to snoop on them, like their ISP. You as the blog owner might not care, but your visitors might. If you don't care about your visitors, that's fine, but some people do.
As for who uses LetsEncrypt, there are a lot of businesses and organizations in between the size of a Microsoft and a small blog that use it. If you read the article, you'll note that LE is celebrating 300M websites protected with their certs. So quite a lot of people find LE useful and want to protect connections to their sites with TLS. If you can't figure out why, perhaps that's more a lack of imagination on your part, than misplaced time and effort on theirs.
As an aside, can you lay off with all the aggressive nonsense? People are replying to you (despite your whining about downvotes). Chill out and maybe take some time away from the keyboard when you're all worked up like that.
[0] Unfortunately SNI will often still leak the domain name of the TLS-protected site being visited, but an encrypted version of SNI is being worked on to close that hole.
Having people do things without understanding what exactly they are doing is a good way to create a website with a very good ssl certificate and their private key available on the website itself… or similar issues.
And Josh is the ED of the Internet Security Research Group, of which Lets Encrypt is just one product/service. As mentioned in his letter, they also run and support Prossimo (https://www.memorysafety.org) -- so the Rust drivers and memory safe kernel are directly in their area of interest and are something they're investing in and supporting.
A clever design aspect of Let’s Encrypt is the deliberately short expiry. That forces administrators to automate the issuance and renewal process.
Not to mention that you’re not supposed to “download” the private key!
The whole idea of PKI is to generate the private key locally and then have a CA sign only the public part.
If you’re doing anything else you’ve undermined the entire purpose of the thing.
I mean you are literally -- not figuratively -- handing your secrets over to Russian hackers and complaining about the people politely showing you how to make your systems safe.
I know better what am I supposed to do. Type "download letsencrypt certificate online" in the Google and you'll find out what I'm talking about. You can think of forcing administrators all the day while Internet is full of expired letsencrypt websites that I regularly stumble upon. The world does not work like that. Letsencrypt should serve its users, not force them onto anything. If I think that I should generate key online, provide me this service with sane implementation on a safe website. If you won't, I'll download it from the "Russian hackers". ACME is awesome, but it's not always suitable, sometimes I want to get certificate manually and that's OK. I remember chinese websites issuing 3-year certificates. Wosign or something like that. That was the best experience I've ever had.
If people want longer certificate lifespans, they can get their certificates elsewhere. Part of the deal with getting a free certificate is that you're supposed to set up autorenewal with ACME. If you can't or don't want to do that, there are plenty of other CAs out there that will get you a long-life certificate.
I partly agree with you, however it's possible for devices to have limited access to the internet, or even no direct access but still be accessible to devices that are on the internet.
If I have a smart device at home I may put it on a network that has no outgoing access to the internet, but it would still be nice to be able to connect to it with a web browser without getting angry expired certificate warnings.
It's not the worst problem to have, and I don't think it's easy to fix, but it's still annoying.
> Type "download letsencrypt certificate online" in the Google
> generate key online, provide me this service with sane implementation on a safe website
Well there's your problem right there. Either go on youtube and watch some videos about how TLS works or just use an http server like Caddy that automatically generates TLS certs and renews them with Let's Encrypt.
> Letsencrypt should serve its users, not force them onto anything.
The only way they can serve users is by forcing them to do the right thing.
You're insisting on doing the wrong thing and shouting at the people that are telling you how to do it right.
An analogy would be the equivalent of "not your wallet, not your crypto". Literally millions of naive crypto enthusiasts have just had $9B stolen from them by FTX because they didn't grasp this basic concept. They just wanted something convenient.
With something like PKI or cryptocoins, there are no shortcuts to security.
It's like sticky-taping your key to your locked front door.
No one is stopping you from getting a 1-year cert from another CA and using that.
If you do not like the process LetsEncrypt uses, then you are not in their target market. That's fine; move on and use something else.
> I remember chinese websites issuing 3-year certificates. Wosign or something like that. That was the best experience I've ever had.
I remember Wosign! Man, what a terrible experience. The last thing I want is be forced to do system administration tasks manually by clicking around on a website. To be fair, it was great that it was available for its time, but I would never want to go back to something like that.
Many Linux distros have Certbot packages to manage the generating of certs and even updating your Apache and Nginx configs to use them. The renewals are also automatic and painless. I've even used win-acme on Windows as another example of an Acme client implementation.
Before Letsencrypt, SSL signing was cumbersome and downright scary sometimes. With cPanel + letsencrypt (or whatever their default Auto SSL provider is [0]), it's a few clicks and done. If there's a downside, I have never seen nor heard of it.
Side note: I was expecting this CEO letter to end with layoffs.
I used to configure all of this manually on Apache following crappy instructions from online certificate providers. Copying .pem, .key, .csr files PRAYING Apache would start without complaining.
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.
Those instructions were always so clunky as was the process.
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.
Browsers did away with it because it says nothing about the actual security status of a page compared to any other SSL page. All it means is that the organization was verified.
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.
And make it almost impossible to use an out of date or self-signed cert. Some browsers make you click 3 times you know what you are doing, others don't seem to let you at all.
From the client perspective, the difference between a self-signed certificate and a fake one that's part of MITM, etc., is completely invisible. It should be hard to get to ostensibly secured sites that can't prove they are who they say they are, and you don't want to train uses to just click through.
It's not invisible. An expired certificate is treated as worse than no certificate. All I want is for it to be easy enough to view it as an insecure site and stop trying to force me to https when there is a bad cert.
> I'm still old school but can set this up all using the letsencrypt command line utilities that configure everything for me.
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.
I have absolutely no issue with Nginx, and still use it here and there. It's just good to see something public about the use of Apache that's current, as I'm more comfortable with its usage and configuration.
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).
You forget: expensive! As an individual, buying my own SSL certificate was too expansive to be worthwhile for my own little projects. With Letsencrypt, that's not even a factor
Let's encryt is a protocol, ACME, that can be implemented by any number of independent actors. Yes, it takes time, energy and money, but it is doable. And if it is possible to switch away from a bad actor, there is more incentive to not being a bad actor.
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.
There are a lot of reasons. The real reason DANE isn't deployed is that DNSSEC isn't deployed, and DNSSEC isn't deployed because (1) it's not an operational security win for most companies, and (2) it has an earned reputation for causing nightmare outages. That's why nothing uses DANE: because there are no DANE records to look up, and the most important (high-traffic, whatever) sites on the Internet disproportionately eschew DNSSEC.
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.
> The best reason DANE isn't deployed is that it vests keying authority with organizations that can't be revoked.
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's one useful exception: say that the Libyan government decided to override bit.ly's DNSSEC records — if all you use is DANE, they've won and they can do that seamlessly for a subset of clients without anyone else noticing. If they try the same thing attacking a DNS-validated certificate system, they lose the covert aspect because Certificate Transparency forces the malicious certificate to be logged in an immutable record.
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.
Let's Encrypt has had such a positive impact, I think I'll start donating to them instead of Wikipedia. They're a lot more subtle with their calls to donate, but they seem to deliver a lot of good things to a lot of users, with a much smaller budget.
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.)
They seem a whole lot less bloated than Wikipedia as well. Given that something around 3% of donations to Wikipedia actually go to the website, they'll be fine with less donations despite what their nag popups suggest.
I stopped donating to Wikipedia after the size of their cash reserves were revealed.
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.
Based on what the parent said only 3% of that $77m is to run the site. The rest is spent on frivolous things I imagine if that's all it takes and they're still soliciting donations.
$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.
18 months runway is included all expenses including wages, awards (that Mozilla gives out, for example to political initiatives), travel, social events and so on.
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).
That's the cost of hosting, not the cost of operations. A business the size of Wikipedia doesn't run itself, and being a nonprofit doesn't magically make operations disappear.
There is no upper bound on how much profit they can take out as wages, and there is no lower bound either. They don't need to match wages with oil companies.
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.
You've confused some words and missed the forest for the trees. It's recommended they spend 65% on program activities for certain third party charity ratings, for which Wikimedia Foundation passes.
Resulting to insults doesn't makes conversations more interesting nor do they convince anyone.
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.
Wikipedia Foundation and Firefox are some of the most well known internet/tech services non-profits out there.
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.
They are not an archive the web, instead electing to remove websites they find distasteful. Not a reliable source of information thus not worth the donation.
This triggered the same thoughts! Especially given the tone, gratefulness, providing a vision... so different from Wikipedia's late FUD and threats strategy to get people (even past and recurring donors) to donate.
I am glad it looks like the IETF ACME specification only addresses the HTTP-01 challenge. I really would like to see improvements made to the DNS-01 challenge before it's ratified, namely, let us publish a public key to a TXT record and use the private key to sign the renewal request. Then I can revoke certbot's access to my DNS records and stop hacking the `.well-known` path.
I'll admit I haven't spent a ton of time thinking through all the implications, but that proposal seems like it comes with some significant security tradeoffs. In particular, you'd lose the ability to prove you control the domain name at the time of certificate renewal. Instead, the key pair approach shows you controlled the DNS records for the domain at some point and your entry has yet to be deleted. From the certificate issuing standpoint, that seems like a much weaker security guarantee. Certbot's access to your DNS records does mean you have to protect those credentials, but the overall requirement seems like a feature rather than a bug.
To be fair, “you controlled the DNS records for the domain at some point and your entry has yet to be deleted” could also describe the HTTP-01 challenge. Admittedly, having the A/AAAA record point to the wrong place is much more likely to be noticed than having a stray TXT record lying around. Perhaps more worrying is the possibility of having a keypair that is legitimately being used to sign certificate requests, but which an attacker also stole a copy of at some point. (Assume that the server owner doesn’t know they were compromised and hence didn’t rotate the key, but the attacker subsequently lost access for some reason.) Such an attacker would likely have also stolen the TLS private key, but that only stays valid for 90 days, whereas for this keypair approach to be useful, the keypair would have to stay valid for a long time or indefinitely…
Does it? Under the approach of storing a public key in DNS, certs can be issued long after the person asking for one has lost access to the website, if the pubkey record hasn't been deleted.
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.
I don't see announcing a public key being much different to PGP or other trust systems. If I say I sign my messages with `63847B4B83930F0C` and you save that information you'll continue to trust that it's me in the future even though there is no proof I still control the private key.
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.
Sorry, can you clarify what you mean by this? The ACME spec (RFC 8555: https://www.rfc-editor.org/rfc/rfc8555.html) fully specified both the HTTP-01 (Section 8.3) and the DNS-01 (Section 8.4) challenges nearly four years ago. The TLS-ALPN-01 challenge was fully specified in RFC 8737 (https://www.rfc-editor.org/rfc/rfc8737) about a year later.
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.
If your concern is that certbot has access to your DNS records, you can set up a CNAME or NS record on _acme-challenge.your-domain and serve the TXT record from a separate, isolated DNS server.
That's an interesting solution to mitigating risk. I wasn't aware that LE would follow a CNAME to a different TXT record.
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.
We need someone to pull a Let's Encrypt in the identity space. A nonprofit that provides the convenience of single-click social login without the tracking. All it would need to do is provide a domain that verifies you control an email address, then let's services do OIDC flows to that domain to log you in.
In all the excitement (I too think that they did massive strides in usability of https to the masses), nobody mentions of systems-level consequences of a single entity holding the keys to 300000000 servers on the internet. They’re now in a “don’t be evil” phase. But the people move on, change, etc. And the companies get sold, rogue, bankrupt…
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…
Just curious what you think the consequences could be? Worst case scenario people would need to find a new CA the next time they need a certificate, right?
I think the worst-case would be a mistake/malice issuing revocations for all of those certificates — that'd take out a ton of different sites and there'd be plenty of chaos around cleaning that up. For example, I note that stackoverflow.com, httpd.apache.org, and nginx.org all use LE certificates which would mean a fair number of people would struggle to install a replacement.
In practice I think that gets a few through, then the mozilla and google servers that push revocation lists start to overload and the admins notice what's going on and shut things down.
Oh, sure but if we’re talking worst-case we’ll assume that the server infrastructure is bulletproof and the admins are all distracted by (maybe Musk just tweeted again).
they don't "hold the keys to the servers" - I believe you have a fundamental misunderstanding of how an X509 SSL PKI works. The people in possession of the private keys generate the cert signing request on their local machine. The CSR is then sent to Letsencrypt. The private keys never leave the system requesting the key signature.
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.
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.
Can somebody from LE explain why "Rust in the kernel" is a story for LE, rather than for Linux itself? Did LE e.g. do the coding? or help? is this a cross-product activity? LE is a system for bootstrapping CA certification, Rust in the kernel is a generalized memory/systems security & safety coding activity.
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?
It's because it's not just a Let's Encrypt end-of-year message: it's an ISRG (Internet Security Research Group) end-of-year message. ISRG runs multiple projects, including both Let's Encrypt and Prossimo. Prossimo is all about using memory-safe languages to replace critical memory-unsafe code, and Prossimo funded a significant chunk of the work to get Rust into the Linux kernel.
154 comments
[ 6.3 ms ] story [ 239 ms ] threadLet’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.
Your post contains some very basic misconceptions. This is going to sound harsh, but I would recommend not putting too much stock in your own opinions on security, and instead to trust the experts.
If LE is ran with the following companies, "Electronic Frontier Foundation; Mozilla Foundation; University of Michigan; Akamai Technologies; Cisco Systems"
What makes them all trade worthy, especially when they're all American? Especially after the whole Richard Stallman. Mozilla, maybe because they were netscape. I have more than enough experience working within security to know that.
I've seen SysOps leak DB's, Passwords in plaintext.. and I've seen it from the age of where such didn't exist to where companies are now installing X security appliances to safe guard there networks. I'm not newb, from 2004 to now, counted 15 years of System and Network engineer experience. Fair from experienced but well seasoned.
Why isn't HackerNews using LetsEncrypt, Google, Netflix, Amazon, if promoted as a great thing. Is what I want to know.
Google: Browser Maintainer that runs entire TLDs, doesn't need a third party, it could just decide to trust itself and 60+% of the market follows.
Amazon: Runs a massive chunk of the internet, it's already MitM'd itself and most other things, doesn't really need a third party for Certs but still uses DigiCert which predates LE and they clearly have a working relationship.
Netflix: See Amazon, HN.
You: Barely exist to the infrastructure of the web as people experience it. Maybe you have a static site you don't care to protect from MitM (could add some malicious scripts or whatever but who cares). Maybe you're a tiny service that offers some 50 users something, their plaintext auth probably shouldn't be readable to just anyone along the network path, but they're not paying you for services so you might not wanna spend much money on that service. Use LE.
Also, if you think LE as a company has the ability to take sites with it if it goes down, you don't really understand Web PKI. At most likely within a year to 3 months you'd need to find a new place if their signatures expire. At worst someone could pretend to be you, but still not read that traffic protected by the old cert.
Why so salty about LE? Especially from a "seasoned" SysEng? Didn't it just make your job easier and safer for those with slightly less experience?
Because it's required, I don't know the companies, I can't trust the companies. I just not happy that four companies run the worlds SSL. There should be another technology that caters to such without having to put all the keys in one basket.
Because it's required, I don't know the companies, I can't trust the companies. I just not happy that four companies run the worlds SSL. There should be another technology that caters to such without having to put all the keys in one basket.
> Didn't it just make your job easier and safer for those with slightly less experience?
No. It makes it harder, because your not teaching someone anyone thing you tell them "click here, click that, done"
Also you're mixing security on data transportation with security of data at rest. Both are important but there are different solutions to each.
Why does Bill Gates use Windows? There must be some fatal flaw in macOS if so many are choosing other operating systems!
Two, you're likely misunderstanding the purpose of SSL and Let's Encrypt. It's not to protect you against the site you're talking to, it's to prevent man in the middle attacks on the way. It ensures you can't walk into a starbucks for an hour and walk away with dozens of facebook logins.
Lastly, the big players don't use Let's Encrypt for reliability and customer service purposes. If you run a blog and your cert screws up, the 3 people visitng your site that week will have to click a few extra buttons to get in.
If you're a microsoft, that can mean thousands if not millions of users hitting this wall they expect not to have, leading to huge costs for customer support and occassionally deeper issues updating certificates. Exactly the same reason Bank of America doesn't use godaddy.com for their domain name.
Before Let's Encrypt, certs cost money from certificate authorities, so not many smaller companies would bother. Now it's streamlined enough that browsers throw scary warnings if you don't have it, which is a massive improvement for everyone using the web.
But should they? I never had any issues running an internet site before this was required. A blog doesn't need SSL. Why are ISP's not more scrutinized to ensure that MITM doesn't happen? Why is it put upon the admin? My blog from 2005 was never hit with MITM.
> If you're a microsoft, that can mean thousands if not millions of users hitting this wall they expect not to have, leading to huge costs for customer support and occassionally deeper issues updating certificates. Exactly the same reason Bank of America doesn't use godaddy.com for their domain name.
So your saying LE is only worth for small-class sites such as "blogs", which than I above said, Why does a blog need SSL? The only reasoning I had which was valid was that "ISP's inject" and if that's the case why are ISP's allowed to get away with injection?
> Your post is 18 minutes old as of me writing and you're already boasting about a lack of replies.
Folks like to down-vote and never reply. I'm sure I might be "flagged" soon too.
> Two, you're likely misunderstanding the purpose of SSL and Let's Encrypt.
Not at all, SSL is the communications protocol. A encrypted-tunnel example made by HTTPS. Verified by a Certificate if we apply laymans terms. LetsEncrypt issues that certification based on the trusted root installed on your computer and if all valid, the brower throws a green badge. I can easily remove the LE root certificate and any LE encrypted site would be invalid.
Yes if you're going to deliberately flamebait I will flag you.
That's not you winning. You made things worse for everyone.
I've made nothing worse for anyone. Those who made it worse for everyone are internet walled gardens and monopolies. If the internet wasn't as corrupted as it now and you deny, telling me Google isn't evil? We would be in a better place with enhancements without the the need for SSL. However not so, evil and mass greed ruined the internet for all since the 80's; heck the 70's.
No, not flame-baiting. Am I not allowed my own view based on my own thoughts? Or am I not allowed free-thought? I'm happy to read everyone's else and take that in. But your denying my own? There's no flame, those opinions are of my own and may not be correct in your eyes but I am still allowed to have.
I'm just talking about this conversation being worse.
> you deny, telling me Google isn't evil?
I didn't say anything about Google.
> No, not flame-baiting. Am I not allowed my own view based on my own thoughts? Or am I not allowed free-thought? I'm happy to read everyone's else and take that in. But your denying my own? There's no flame, those opinions are of my own and may not be correct in your eyes but I am still allowed to have.
You posted "No answers for me? Just what I thought." with the specific intent of annoying people into replying.
I'll agree to disagree on that, the reason is that folk blindly down-vote. It's infuriating. If I hold opinion A which is incorrect, when opinion B could be correct, I then wouldn't get possibly a corrected perspective. At least it sparks a reaction and sights conversation, regardless if annoyance. It allows myself to express how I feel and why I feel. Rather than the hive-mind mentality that if everyone is doing it, its the right think.
> I'm just talking about this conversation being worse.
How? I expressed my opinion. It may not be right, it may be controversial, you may disagree. Yet your post came off as you should have supreme control, you do have many karma points but that still doesn't dictate. I don't doubt your intelligence, nor interactions, myself I am only 33, still learning the world. For all I know you could be god if you believe in such a thing.
> you deny, telling me Google isn't evil?
I'm was laying my beliefs based on the misunderstanding of your post. I misunderstood how "conversation being worse" it happens. However that again is another controversial opinion that the internet is within a very crippled state, for such pointed out above. Again, you may disagree.
Your entitled to such opinion you believe, I'm disappointed that if you did flag me, or that such a feature blocks because what I laid out wasn't out to be argumentative but as free-thought opinion. Maybe more emotional and cynical of than what it should of been but still. Words are tricky and no one person is an expert.
Regardless, mutually. Have a good night
As for who uses LetsEncrypt, there are a lot of businesses and organizations in between the size of a Microsoft and a small blog that use it. If you read the article, you'll note that LE is celebrating 300M websites protected with their certs. So quite a lot of people find LE useful and want to protect connections to their sites with TLS. If you can't figure out why, perhaps that's more a lack of imagination on your part, than misplaced time and effort on theirs.
As an aside, can you lay off with all the aggressive nonsense? People are replying to you (despite your whining about downvotes). Chill out and maybe take some time away from the keyboard when you're all worked up like that.
[0] Unfortunately SNI will often still leak the domain name of the TLS-protected site being visited, but an encrypted version of SNI is being worked on to close that hole.
What do you mean by this?
It's literally a director's job to focus on more than one specific thing.
What are you talking about?
A clever design aspect of Let’s Encrypt is the deliberately short expiry. That forces administrators to automate the issuance and renewal process.
Not to mention that you’re not supposed to “download” the private key!
The whole idea of PKI is to generate the private key locally and then have a CA sign only the public part.
If you’re doing anything else you’ve undermined the entire purpose of the thing.
I mean you are literally -- not figuratively -- handing your secrets over to Russian hackers and complaining about the people politely showing you how to make your systems safe.
Learn about the ACME protocol and certificate automation: https://letsencrypt.org/docs/client-options/
If I have a smart device at home I may put it on a network that has no outgoing access to the internet, but it would still be nice to be able to connect to it with a web browser without getting angry expired certificate warnings.
It's not the worst problem to have, and I don't think it's easy to fix, but it's still annoying.
I don't want LE to waste money supporting such use cases.
Correct, because the CA/Browser Forum no longer permits CAs to issue certificates with validity longer than 13 months:
https://pkic.org/2020/07/09/one-year-certs/
> generate key online, provide me this service with sane implementation on a safe website
Well there's your problem right there. Either go on youtube and watch some videos about how TLS works or just use an http server like Caddy that automatically generates TLS certs and renews them with Let's Encrypt.
The only way they can serve users is by forcing them to do the right thing.
You're insisting on doing the wrong thing and shouting at the people that are telling you how to do it right.
An analogy would be the equivalent of "not your wallet, not your crypto". Literally millions of naive crypto enthusiasts have just had $9B stolen from them by FTX because they didn't grasp this basic concept. They just wanted something convenient.
With something like PKI or cryptocoins, there are no shortcuts to security.
It's like sticky-taping your key to your locked front door.
Or writing your pin code on your credit card.
Or setting your password to "12345".
If you do not like the process LetsEncrypt uses, then you are not in their target market. That's fine; move on and use something else.
> I remember chinese websites issuing 3-year certificates. Wosign or something like that. That was the best experience I've ever had.
I remember Wosign! Man, what a terrible experience. The last thing I want is be forced to do system administration tasks manually by clicking around on a website. To be fair, it was great that it was available for its time, but I would never want to go back to something like that.
What is shady ?
Side note: I was expecting this CEO letter to end with layoffs.
[0] https://docs.cpanel.net/whm/ssl-tls/manage-autossl/
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...
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.
otherwise great news that LE is still doing well as an 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).
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.
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.
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?