Slams!
this post was submitted on 16 Oct 2024
173 points (91.4% liked)
Technology
58719 readers
4743 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
Automated certificate lifecycle management is going to be the norm for businesses moving forward.
This seems counter-intuitive to the goal of "improving internet security". Automation is a double-edged sword. Convenient, sure, but also an attack vector, one where malicious activity is less likely to be noticed, because actual people aren't involved in tbe process, anymore.
We've got ample evidence of this kinda thing with passwords: increasing complexity requirements and lifetime requirements improves security, only up to a point. Push it too far, and it actually ends up DECREASING security, because it encourages bad practices to get around the increased burden of implementation.
Just going to mention my zero-dependency ACME (Let's Encrypt) library: https://github.com/clshortfuse/acmejs
It runs on Chrome, Safari, FireFox, Deno, and NodeJS.
I use it to spin up my wildcard and HTTP certificates. I've personally automated it by having the certificate upload to S3 buckets and AWS Certificates. I wrote a helper for Name.com for DNS validation. For HTTP validation, I use HTTP PUT.
Why have this run in the browser? Why not just have it run on the server and renew in the background?
Any post/article with the word “slammed” in it gets a downvote and a no-read from me. That word needs to disappear from journalism/forums/life/etc.
This is the one case where I'd make an exception. I read through the threads, it got particularly heated.
As someone who creates custom domain name applications, FUCK THEM WITH A PINEAPPLE SPIKY SIDE FIRST. This problem is on par with timezones for needless complexity and communication disasters. Companys and advertisers are now adding man in the middle certs for additional data collection/visibility. If the ciphers not cracked, changing the certs exposes significantly more failure, than letting one get a little stale.
Sysadmin used slam! It's super effective!
Why not just autorenew on a schedule?
I use Lets Encrypt, and my certs get renewed automatically without me thinking about it.
Mostly customer provided certs, high end clients make all kinds of stupid requests like the aforementioned man-in-the-middle chain sniffers, clients that refuse DNS validation, clients that require alternate domains to be updated regularly. Management is fine for mywebsite.com, but how are you solving an EV on the spoofed root prod domain, with an sso cert chain for lower environments on internal traffic that is originally provided by a client? And do you want the cs reps emailing each other your root cert and (mistakingly) the key? I've been given since SCARY keys by clueless support engineers. I don't want to do this every 3 months.
Sounds like a change in company policy, because AFAIK, there's no good reason for pretty much any of that.
Sounds like you don't do contact negotiations, if someone will pay 2 million to appear on their root domain, you'll sit down and figure it out for a couple hours.
Unrelated to the topic, but I deal with a database storing timestamps.
In local time.
For systems all around the world.
You'll see current entries timestamped 12:28 from eastern Europe followed by ones 6:28 from America and then another 11:28 from central Europe.
Without offset.
Ew. Just store UTC timestamps and do optional translation on the client using whatever the client sets up for their timezone. It's not hard...
The Register is deliberately tabloid-like in style (right up to the "red top" site banner), but is good quality (at least when I read it).
They won't write an article about science without using the word "boffins" either. It's just their thing.
Part of this might be my general disdain towards sysadmins who don't know the first thing about technology and security, but I can't help but notice that article is weirdly biased:
Over the past couple of days, these unsung heroes who keep the internet up and running flocked to Reddit to bemoan their soon-to-be increasing workload.
Kind of weird to praise random Reddit users who might or might not actually sysadmins that much for not keeping up with the news, or put any kind of importance onto Reddit comments in the first place.
Personally, I'm much more partial to the opinions of actual security researchers and hope this passes. All publicly used services should use automated renewals with short lifespans. If this isn't possible for internal devices some weird reason, that's what private CAs are for.
I'm on the side of "automate it all and stop whining", but I do think it's important not to so readily dismiss the thoughts and opinions of those this directly affects in favour of the opinions of the security researchers pushing the change.
There are some legitimate issues with certain systems that aren't easily automated today. The issue is with those systems needing to be modernised, but there isn't a big push for that.
I'd be more concerned as well if this would be an over-night change, but I'd say that the rollout is slow and gradual enough that giving it more time would just lead to more procrastination instead, rather than finding solutions. Particularly for those following the news, which all sysadmins should, the reduction in certificate lifespan over time has been going on for a while now with a clear goal of automation becoming the only viable path forward.
I'll also go out on a limb and make a guess that a not insignificant amount of people only think that their "special" case can't be automated. I wouldn't even be surprised if many of those could be solved by a bog-standard reverse-proxy setup.
Exactly. My "special case" took a little more care, but it works completely fine. Here's my setup:
- TCP proxy at edge -> wireguard tunnel using SNI to route to the right service
- reverse proxy that handles all TLS for all services on its device (renewals and crypto)
- HTTP services behind a firewall that only communicate w/ proxy
I have my router configured to resolve DNS to #2, so I don't need to hit the WAN to access local services over TLS, and it uses the exact same cert as WAN traffic and the browser is happy.
This is about as exotic as I can think of, and it still works just fine for TLS renewals, and it's 100% automated. I do need to leave HTTP open (it only serves acme endpoints, so whatever), but I could also close that down and have the renewal process open that temporarily if needed.
The only special case I can think of is a device that rarely turns on, which is incredibly rare these days (you'd generally have an always-on gateway that uses self-signed certs or something for those devices that stay off).
load more comments
(1 replies)
I'm not an "actual security researcher" but I was an "actual security officer" at a reeeeally large shop.
Yes, researchers are right. But they don't dictate what else we have to let slide to allow time to work this constantly.
And neither are they on the hook for it.
They can be pedants, but they can't do it blind.
I'm sorry, but has no-one heard of https://letsencrypt.org that issues certificates via API for free?
I would not be surprised if certificates at some point will be issued for each session.
AWS makes this impossible in a few places such as a fair number of ACM use-cases.
I think your cert-per-session idea is interesting. We’d need significant throughput and processing boosts to make that happen, probably at least on the order of 10X computing speeds and 10X transmission speeds across the board minimum. These operations are computationally intense and add data to the wire so, for example, a simple Lemmy server with hundreds of users slows to a crawl and a larger site eg Mastodon goes to dialup speeds or worse. You can test at home by trying to generate an x509 self-signed cert before connecting to a website every time.
It's not the issuance that's the headache, it's the installation. There are more things that need valid certs than just webservers
load more comments
(6 replies)
I'm sorry, but have you ever needed to manage some certificates for a legacy system or something that isn't just a simple public facing webserver?
Automation becomes complicated very quickly. And you don't want to give DNS mutation access to all those systems to renew with DNS-01.
Ahh yes the: we can't have self signed certificates for security reasons but also can't open up the environment to the web, and we dont have our own CA server, trifecta.
Solution: awkward, manual, certificate import process from a 3rd party vendor.
Even if you have an internal CA, few appliances support this kind of automation. At best, they have an API, and you get to write that automation yourself for each appliance.
load more comments
(1 replies)
load more comments
(5 replies)
If approved, it will affect all Safari certificates, which follows a similar push by Google, that plans to reduce the max-validity period on Chrome for these digital trust files down to 90 days.
Max lifespans of certs have been gradually decreasing over the years in an ongoing effort to boost internet security. Prior to 2011, they could last up to about eight years. As of 2020, it's about 13 months.
Apple's proposal would shorten the max certificate lifespan to 200 days after September 2025, then down to 100 days a year later and 45 days after April 2027. The ballot measure also reduces domain control validation (DCV), phasing that down to 10 days after September 2027.
And while it's generally agreed that shorter lifespans improve internet security overall — longer certificate terms mean criminals have more time to exploit vulnerabilities and old website certificates — the burden of managing these expired certs will fall squarely on the shoulders of systems administrators.
Over the past couple of days, these unsung heroes who keep the internet up and running flocked to Reddit to bemoan their soon-to-be increasing workload. As one noted, while the proposal "may not pass the CABF ballot, but then Google or Apple will just make it policy anyway…"
...
However, as another sysadmin pointed out, automation isn't always the answer. "I've got network appliances that require SSL certs and can't be automated," they wrote. "Some of them work with systems that only support public CAs."
Another added: "This is somewhat nightmarish. I have about 20 appliance like services that have no support for automation. Almost everything in my environment is automated to the extent that is practical. SSL renewal is the lone achilles heel that I have to deal with once every 365 days."
Until next year, anyway.
Lame. 45 days? 10 days for DCV? How common are exploits involving old certificates anyway? And automated cert management is just another exploit target. Do they seriously think an attacker who pwns a server can't keep the automatic renewals running?
The solution, according to Sectigo's Chief Compliance Officer Tim Callan, is to automate certificate management — unsurprising considering the firm sells software that does just this.
view more: next ›