161–170 of 321 posts
Earlier quoted context omitted.
How so?
Presumably, someone could MITM a CA, and get their own domain validated certificate to another site. The cert may protect you from MITM in a coffee shop, but it doesn't necessarily help you against state-level actors.
The amount of money I've paid for this... I recon some of these providers are going under soon?
> I recon some of these providers are going under soon? I really hope so. The cost to providers is exactly the same for a wildcard and a standard certificate, and yet they costs hundreds of dollars. It's unbelievable it's lasted this long
First, congrats, this is great news! There's a lot of use cases out there that require a wildcard cert or work far better with them. > It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet. Please don't do this. It will break millions of sites needlessly. Most installations of lets encrypt plugins aren't going to auto update to v2. A lo…
DNS providers and domain name registration companies are probably going to get pestered about API access for updating TXT DNS records now... :)
Earlier quoted context omitted.
Presumably, someone could MITM a CA, and get their own domain validated certificate to another site. The cert may protect you from MITM in a coffee shop, but it doesn't necessarily help you against state-level actors.
It’s currently standard for CAs to host multiple verifiers in multiple jurisdictions, to reduce the chances of this happening, afaik.
Earlier quoted context omitted.
If not SSL, then they'd go away at the point some other technical change dropped. Or do you suggest "we" continue using broken protocols forever in order to preserve them? Do you still support telnet to accommodate people who can't handle `ssh-keygen`? In any case, (a small subset of) the random enthusiast sites and such are close to the only reason I use a browser recreationally anymore. I absolutely agree with you.…
My point is that those sites don't need to be any more secure than they are. A hobbyist website written in HTML in Notepad with only text and images that can be run on IE 5.0 might not require HTTPS and Google and others might change that.
Earlier quoted context omitted.
> The preferable end-of-life date for ACMEv1 should be never. As would be the preferable end-of-life date for SSLv3 and HTTP.
The SSL zealotry drives me nuts. The infosec community screams constantly about "HTTPS everywhere", but they either don't know or don't care about all the effort and pain they're creating for developers who just want their software to work. How many perfectly good sites will be marked ominously as "insecure" by Chrome in the next few months? Sites that were working just fine until someone at Big G decided they weren'…
Your software does not work if it is not secure. Security is a correctness problem.
Earlier quoted context omitted.
> developers who just want their software to work. Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with. > they either don't know or don't care about all the effort and pain they're creating You have not been paying attention to the hundreds of tools available to make HTTPS painless. > until someone at Big G decided they weren't. And Mozilla. And countle…
What about hosting HTTP content because you verify GPG signatures upon download? These content would then be super easy to cache on the local network. HTTPS defeats this and makes it uncachable. I hardly ever see people talk about this use case and how to solve it with https everywhere. AND it's super widely used: e.g. debian repositories.
If you're doing this, then you've made your own HTTP client so you can do whatever you want.
"HTTPS Everywhere" is a web browser thing.
1. Use acme.sh: https://github.com/Neilpang/acme.sh
acme.sh --issue -d *.example.com --dns
The amount of money I've paid for this... I recon some of these providers are going under soon?
I'll happily pay money to get a cert that expires in 3 years instead of 90 days. Some of us don't feel like faffing about with cert renewal every quarter. (I know there are tools and clients that can "make it seamless" - until the ACME endpoints are down or something).
No way. Every time I've worked with an organization with three years expiry it's guaranteed they have no idea, after three years how to even renew the cert. They are effectively longer in many cases than the hiring cycle and for larger organizations can be a complete nightmare. No one wants to invest in time in automation, training, tracking, etc., because it's so far down the road. The 90 day model makes much more sense because it requires automation. In terms of the ACME endpoints being down, I'm not going to say that won't happen but renewal starts 30 days before the cert expires and if Let's Encrypt's ACME endpoints are down for 30 days or longer there's a good chance we are all dealing with something far more dire than cert renewal at that point.