| ▲ | _bin_ 4 days ago |
| Is there an actual issue with widespread cert theft? That seems like the primary valid reason to do this, not forcing automation. |
|
| ▲ | cryptonym 4 days ago | parent | next [-] |
| Let's Encrypt dropped support for OCSP. CRL doesn't scale well. Short lived certificate probably are a way to avoid certificate revocation quirks. |
| |
| ▲ | Ajedi32 4 days ago | parent [-] | | It's a real shame. OCSP with Must-Staple seemed like the perfect solution to this, it just never got widespread support. I suppose technically you can get approximately the same thing with 24-hour certificate expiry times. Maybe that's where this is ultimately heading. But there are issues with that design too. For example, it seems a little at odds with the idea of Certificate Transparency logs having a 24-hour merge delay. | | |
| ▲ | NoahZuniga 3 days ago | parent | next [-] | | Also certificate transparency is moving to a new standard (sunlight CT) that has immediate merges. Google requires maximum merge delay to be 1 minute or less, but they've said on google groups that they expect merges to be way faster. | |
| ▲ | lokar 3 days ago | parent | prev [-] | | The log is not really for real time use. It’s to catch CA non-compliance. |
|
|
|
| ▲ | dboreham 4 days ago | parent | prev | next [-] |
| I think it's more about revocation not working in practice. So the only solution is a short TTL. |
|
| ▲ | trothamel 4 days ago | parent | prev | next [-] |
| I suspect it's to limit how long a malicious or compromised CA can impact security. |
| |
| ▲ | hedora 4 days ago | parent | next [-] | | Equivalently, it also maximizes the number of sites impacted when a CA is compromised. It also lowers the amount of time it’d take for a top-down change to compromise all outstanding certificates. (Which would seen paranoid if this wasn’t 2025.) | | |
| ▲ | lokar 3 days ago | parent [-] | | Mostly this. Today of a big CA is caught breaking the rules, actually enforcing repairs (eg prompt revocation ) is a hard pill to swallow. |
| |
| ▲ | rat9988 4 days ago | parent | prev [-] | | I think op is asking has there been many real case scenarios in practice that pushed for this change? |
|
|
| ▲ | chromanoid 4 days ago | parent | prev [-] |
| I guess the main reason behind this move is platform capitalism. It's an easy way to cut off grassroots internet. |
| |
| ▲ | gjsman-1000 4 days ago | parent | next [-] | | If that were true, we would not have Let's Encrypt and tools which can give us certificates in 30 seconds flat once we prove ownership. The real reason was Snowden. The jump in HTTPS adoption after the Snowden leaks was a virtual explosion; and set HTTPS as the standard for all new services. From there, it was just the rollout. (https://www.eff.org/deeplinks/2023/05/10-years-after-snowden...) (Edit because I'm posting too fast, for the reply): > How do you enjoy being dependent on a 3rd party (even a well intentioned one) for being on the internet? Everyone is reliant on a 3rd party for the internet. It's called your ISP. They also take complaints and will shut you down if they don't like what you're doing. If you are using an online VPS, you have a second 3rd party, which also takes complaints, can see everything you do, and will also shut you down if they don't like what you're doing; and they have to, because they have an ISP to keep happy themselves. Networks integrating with 3rd party networks is literally the definition of the internet. | | |
| ▲ | nottorp 4 days ago | parent | next [-] | | How do you enjoy being dependent on a 3rd party (even a well intentioned one) for being on the internet? Let's Encrypt... Cloudflare... useful services right? Or just another barrier to entry because you need to set up and maintain them? | | |
| ▲ | icedchai 4 days ago | parent [-] | | You are always dependent on a 3rd party to some extent: DNS registration, upstream ISP(s), cloud / hosting providers, etc. | | |
| ▲ | nottorp 4 days ago | parent [-] | | And now your list has 2 more items in it … | | |
| ▲ | icedchai 3 days ago | parent [-] | | Does it? I need to get a cert from somewhere, whether that's Lets Encrypt for free, or some other company that charges $300/year for effectively the same thing. |
|
|
| |
| ▲ | chromanoid 4 days ago | parent | prev [-] | | I dunno. Self-hosting w/o automation was feasible. Now you have to automate. It will lead to a huge amount of link rot or at least something very similar. There will be solutions but setting up a page e2e gets more and more complicated. In the end you want a service provider who takes care of it. Maybe not the worst thing, but what kind of security issues are we talking about? There is still certificate revocation... | | |
| ▲ | icedchai 4 days ago | parent [-] | | Have you tried caddy? Each TLS protected site winds up being literally a couple lines in a config file. Renewals are automatic. Unless you have a network / DNS problem, it is set and forget. It is far simpler than dealing with manual cert renewals, downloading the certificates, restarting your web server (or forgetting to...) | | |
| ▲ | chromanoid 4 days ago | parent [-] | | Yes, but only for internal stuff. I prefer traefik at the moment. But my point is more about how people use wix over free webspace and so on. While I don't agree with many of Jonathan Blow's arguments, but news like this make me think of his talk "Preventing the
collapse of civilization" https://m.youtube.com/watch?v=ZSRHeXYDLko | | |
| ▲ | ikiris 3 days ago | parent [-] | | Traefik without certmanager is just as self inflicted a wound. It’s literally designed to handle this for you. | | |
| ▲ | chromanoid 3 days ago | parent [-] | | I have to use an internal cert out of my control anyways. For personal projects I switched to web hosters after some bad experience. But I vividly remember setting up my vps as a teen. while I understand the reasoning it's always sad to see those simpler times go away. and sometimes I don't see the reasoning behind and suspect it's because some c-suites don't see big harm, since it ought to make things safer and those people that are left in the dust don't count anyway... |
|
|
|
|
| |
| ▲ | bshacklett 4 days ago | parent | prev | next [-] | | How does this cut off the grassroots internet? | | |
| ▲ | chromanoid 4 days ago | parent [-] | | It makes end to end responsibility more cumbersome. There were days people just stored MS Frontpage output on their home server. | | |
| ▲ | icedchai 4 days ago | parent | next [-] | | Many folks switched to Lets Encrypt ages ago. Certificates are way easier to acquire now than they were in "Frontpage' days. I remember paying 100's of dollars and sending a fax for "verification." | | |
| ▲ | whs 4 days ago | parent | next [-] | | Do they offer any long term commitment for the API though. I remembered that they were blocking old cert manager clients that were hammering their server. You can't automate that (as it could be unsafe, like Solarwinds) and they didn't give one year window to do it manually either. | | |
| ▲ | icedchai 4 days ago | parent [-] | | You do have a point. I still feel that upgrading your client is less work than manual cert renewals. |
| |
| ▲ | chromanoid 4 days ago | parent | prev [-] | | I agree, but I think the pendulum just went too far on the tradeoff scale. |
| |
| ▲ | ezfe 3 days ago | parent | prev [-] | | I've done the work to set up, by hand, a self-hosted Linux server that uses an auto-renewing Let's Encrypt cert and it was totally fine. Just read some documentation. |
|
| |
| ▲ | jack0813 4 days ago | parent | prev [-] | | There are very convenient tools to do https easily these days, e.g. Caddy. You can use it to reverse proxy any http server and it will do the cert stuff for you automatically. | | |
| ▲ | chromanoid 4 days ago | parent [-] | | Ofc, but you have to be quite techsavy to know this and to set this up. It's also cumbersome in many low-tech situations. There is certificate revocation, I would really like to see the threat model here. I am not even sure if automation helps or just shifts the threat vector to certificate issuing. |
|
|
