10 Years of Let's Encrypt
151–160 of 361 posts
Re: 10 Years of Let's Encrypt
#152It’s easy to forget how awful TLS was before Let’s Encrypt: you’d pay per-hostname, file tickets, manually validate domains, and then babysit a 1-year cert renewal calendar. Today it’s basically “install an ACME client once and forget it” and the web quietly shifted from The impressive bit isn’t just the crypto, it’s that they attacked the operational problem: automation (ACME), good client ecosystem, and a nonprofit…
We had some legacy systems on our network that needed certs and had various subdomains that prevented us from just having a wildcard cert. It ended up that we needed a few dozen subdomains with wildcard certs for each, and it was all for internal traffic between them.
The company we were using wanted to charge us $30,000 for a one year cert with that many wildcards.
We said fuck that, created our own CA, generated a big wildcard cert, and then installed the CA on the few thousand servers as a trusted root. A few months later and we are just using let's encrypt for everything, for free.
I can't believe there is a market for $30,000 certs anymore. We were just shocked that that was deemed a reasonable price to charge us.
Re: 10 Years of Let's Encrypt
#153Re: 10 Years of Let's Encrypt
#154Re: 10 Years of Let's Encrypt
#155Earlier quoted context omitted.
It was easy to provide the information for an existing business you're completely unrelated to. Reliably verifying that a person actually represents a company isn't possible in most of the world.
Many countries has official register of companies with at least post box address. Requiring to answer a physical letter sent to an address from the central register will be much more reliable.
Re: 10 Years of Let's Encrypt
#156Earlier quoted context omitted.
Not really the point of ssl certs though. And I'm pretty sure those limitations are the smallest hurdle, most people wouldn't even care checking.
The "most people won't care argument" doesn't inspire confidence in the authenticity of the website. It's essentially a self-signed cert that anyone could make with the false security of a root certificate authority.
There are two authentication properties that one might be interested in:
1. The binding of some real world identity (e.g., "Google") to the domain name ("google.com). 2. The binding of the domain name to a concrete Web site/connection.
The WebPKI is responsible for the second of these but not the first, and ensures that once you have the correct domain name, you are talking to the right site. This still leaves you with the problem of determining the right domain name, but there are other mechanisms for that. For example, you might search for the company name (though of course the search engines aren't perfect), or you might be given a link to click on (in which case you don't need to know the binding).
Yes, it is useful to know the real world identity of some site, but the problem is that real world identity is not a very well-defined technical concept, as names are often not unique, but instead are scoped geographically, by industry sector, etc. This was one of the reasons why EV certificates didn't really work well.
Obviously, this isn't a perfect situation, but the real world is complicated and it significantly reduces the attack surface.
Re: 10 Years of Let's Encrypt
#157Re: 10 Years of Let's Encrypt
#158Earlier quoted context omitted.
I've seen people complain that Let's Encrypt is so easy that it's enabling the forced phaseout of long-lived certificates and unencrypted HTTP. I sort of understand this, although it does feel like going "bcrypt is so easy to use it's enabling standards agencies to force me to use something newer than MD5". Like, yeah, once the secure way is sufficiently easy to use, we can then push everyone off the insecure way; th…
Yeah, I hate how it made housing things locally without a proper domain name very difficult. My router _shouldn't_ have a globally recognized certificate, because it's not on a publicly visible host. There's certainly advantages to easily available certificates, but that has enabled browsers and others to push too far; to be sure, though, that's not really a fault of Let's Encrypt, just the people who assume it's som…
Re: 10 Years of Let's Encrypt
#159Earlier quoted context omitted.
When you request an EV. They call you by the phone number that you give to ask if you requested a certificate. That was the complete extend of the validation. I could be a scammer with a specificity designed domain name and they would just accept it, no questions asked.
EV certs also showed the legal name of the company that requested the certificate - that was an advantage.
If anything, it's a disadvantage. People are going to be less cautious about things like the website's domain name if they see a familiar-sounding company name in that green bar. "stripe-payment.com" instead of "stripe.com"? Well, the EV says "Stripe, Inc.", so surely you're on the right website and it is totally safe to enter your credentials...
Re: 10 Years of Let's Encrypt
#160Earlier quoted context omitted.
Cloudflare uses HTTP to connect to your website before caching the content. I’ve always found it highly insecure. You could have HTTPS with Letsencrypt, but you need to deactivate Cloudflare when you want to renew (or use the other validation that is complex enough that I didn’t succeed to do it).
Don't pick on this particular SSL requirement, pick on the deluge of requirements that only make sense for a site that sells something or handles personal data (i.e. has accounts). They get extended to $RANDOM_SITE that only serves static text and the occasional cat photo for no good reason except "your cats will be more secure!".
Parent: those innocuous cat photos are fine in the current political climate… “First they came for the cat pic viewers, but I did not speak up…”