Sigh.
Just got told by a company internal app that it's time to change my password.
Can we please stop with the fake #security? My password is a long string of randomly generated characters. Nobody's going to guess it any time soon.
Timeline
Post
Remote status
Context
17
@argv_minus_one I still believe in password rotation on long intervals (1 year min). Passwords that get spread across multiple systems (e.g. LDAP, OIDC) get used and abused and shoved into god knows what by people and it contains the damage to some extent of a lost first factor which happens all the time.
@7666 @argv_minus_one 1 year is reasonable and I would go even lower to 6 months at max. That said, there are companies that force password changes every 2 months and sometimes even faster. At that point it misses the point completely, because much more employees will just stick some number at the end or capitalize one letter and be done with it.
@phnt @argv_minus_one I am waiting for the inevitable screeching about how passwords should last forever and shouldn't be rotated until confirmed compromised and then I'll go "okay! now do that for TLS certificates!"
As for public CAs requiring TLS certificates to be rotated every 21 seconds, they're doing that because
1. OCSP has epically failed,
2. everybody had to go back to CRLs, and
3. in order for CRLs to not get monstrously huge, certificates must expire quickly so they can be quickly deleted from the CRL.
None of this applies to company internal stuff. Long-lived certificates are still fine in those environments.
@argv_minus_one @phnt Expiration and CRL entry are not the same. Certificates are timestamped with an expiration date which is approved by the CA. A CRL only gets updated when a certificate is explicitly revoked by the CA so that when clients reach out to the CRL they find the cert and stop trusting it, even if it is a 100% valid, in-date cert. You have this sideways.
The only reason why certificates, which generally live in a protected space untouched by users, have a more aggressive rotation period than passwords, is because of domain / resource transfers. At the time of signing, the domain / resource that was signed for could have changed hands, but the certificate would still be valid. This is where a CRL would come in, because prior to transfer you'd revoke the cert, but this is apparently too hard for CAs.
The correct path is to fix OCSP or CRL distribution, and not force the rest of us to fix it on their behalf by cycling certs like maniacs.
The only reason why certificates, which generally live in a protected space untouched by users, have a more aggressive rotation period than passwords, is because of domain / resource transfers. At the time of signing, the domain / resource that was signed for could have changed hands, but the certificate would still be valid. This is where a CRL would come in, because prior to transfer you'd revoke the cert, but this is apparently too hard for CAs.
The correct path is to fix OCSP or CRL distribution, and not force the rest of us to fix it on their behalf by cycling certs like maniacs.
@7666 @argv_minus_one You can't fix the system when browsers are basically the only ones steering it. The various hacks needed to make XMPP S2S connections not freak out after LE stopped issuing certs for client auth should have never existed in the first place.
Then there's also this: https://letsencrypt.org/2026/02/24/rate-limits-45-day-certs
Then there's also this: https://letsencrypt.org/2026/02/24/rate-limits-45-day-certs
Removing the TLS Client EKU is an epic fail and has made a lot of people justifiably upset, but that isn't the same thing as certificate rotation.
I certainly wouldn't mind if someone offered a better alternative to this rapid certificate rotation as it is rather inelegant, but I can't think of one. Can you?
Also, OCSP was even more inelegant. As someone who was dreading having to actually use it in a non-browser client app to validate a server certificate: good riddance.
@argv_minus_one @7666 It's the shorter lifetime of certs that annoys me. It will be 45 days in a few years, then what? 30 days and 14 days? It doesn't make sense especially in the context where seemingly no ACME client can properly request certificates. I've had issues with certbot, switched to acme.sh with the dynamic web server reconfiguration, that didn't work reliably either. Then switched to acme.sh with webroot where the only way to fail is not to place a single file in a predefined directory and it still manages to fail ~20% of the time for some reason. The only ACME client that hasn't failed me is OpenBSD's one. In a few years, we'll all be running an ACME client on a daily cronjob I guess.
@phnt @7666 @argv_minus_one none of this would even be a problem if revocation wasn't such a pain either
@i @7666 @argv_minus_one Good luck getting your domain registrar's DNS to cooperate or running your own.
I'm not familiar with DANE, but according to Wikipedia https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities it has the rather serious problem that everything is signed with 1024-bit RSA.
This is…not great.
Replacing CAs with DNS server operators sounds like an okay idea in theory, but it'll only work if DNS server operators are prepared for the responsibility, which it doesn't sound like they are. Not yet, at least.
@argv_minus_one @7666 @i DANE's only actual deployment is with MTAs where it is used to ensure you aren't getting downgraded with a MiTM.
And even there it flopped hard because it's annoying to get running and maintain.
@phnt @7666 @argv_minus_one and also there's a circular loop where the initial thing wasn't good enough and now it's never allowed to ever be adopted because vendors are just fine with CA's, securing dnssec with 256bit elliptic sigs (https://www.ietf.org/rfc/rfc6605) is old as hell, and people still complain about the initial rsa1024 keys
it's like saying saying https is insecure because ssl or tls1.0 existed before
it's like saying saying https is insecure because ssl or tls1.0 existed before
Replies
0Fetching replies…