Sysadmins rage over Apple's 'nightmarish' SSL/TLS cert lifespan cuts(theregister.com)
theregister.com
Sysadmins rage over Apple's 'nightmarish' SSL/TLS cert lifespan cuts
https://www.theregister.com/2024/10/15/apples_security_cert_lifespan/
30 comments
Is there any reason for a 45 day limit? I was unaware that Let's Encrypt's super long certificate validity period posed such an existential threat to internet security that it needed to be halved.
The problem is that sysadmins don’t want to actually fix there setups to make certificate rolling easy.
And every single time there’s a compromised or busted CA, or some certificate flaw, these same incompetent sysadmins get up in arms about how they cannot possibly perform one of the most basic and fundamental tasks of running connected services in less than a week.
This is a task that should be almost entirely if not completely automated, and should take in the order of hours.
This is their own fault.
They’ve had well over a decade of knowing they had to fix this fundamental failure in their systems and they did nothing.
That this change is a problem demonstrates incompetence. if it’s actually surprising (and it’s not just “we bitched before and it worked”) then they’re actually literal morons: this has been best practice for over a decade and repeatedly and clearly stated as what the future was going to be.
This change is not new.
And every single time there’s a compromised or busted CA, or some certificate flaw, these same incompetent sysadmins get up in arms about how they cannot possibly perform one of the most basic and fundamental tasks of running connected services in less than a week.
This is a task that should be almost entirely if not completely automated, and should take in the order of hours.
This is their own fault.
They’ve had well over a decade of knowing they had to fix this fundamental failure in their systems and they did nothing.
That this change is a problem demonstrates incompetence. if it’s actually surprising (and it’s not just “we bitched before and it worked”) then they’re actually literal morons: this has been best practice for over a decade and repeatedly and clearly stated as what the future was going to be.
This change is not new.
> posed such an existential threat to internet security that it needed to be halved.
It's not. It's just patronizing one-size-fits-all security tunnel-visioners doing their patronizing one-size-fits-all security tunnel-vision thing.
It's not. It's just patronizing one-size-fits-all security tunnel-visioners doing their patronizing one-size-fits-all security tunnel-vision thing.
It's like people completely forget about the "A" in the CIA triad.
They broke it playing like cowbell. Triad? Only choice is 'yes'
It’s short enough to force people to either automate cert renewal or at least have a plan for doing it manually.
The existential threat is stuff like appliances or servers that haven’t had a cert rotation in 6 years and now no one remembers the password or whatever. Now people will have to log in every 45 days, so that’s much less likely.
I’m not really sure it is Apples or the CAs place to require that, but I think that’s the logic.
The existential threat is stuff like appliances or servers that haven’t had a cert rotation in 6 years and now no one remembers the password or whatever. Now people will have to log in every 45 days, so that’s much less likely.
I’m not really sure it is Apples or the CAs place to require that, but I think that’s the logic.
Maybe it’s time for an ACME extension or some other mechanism to make this sort of certificate renewal less absurdly complex and baroque.
Right now, for a device to get a certificate via ACME, it needs to do one of:
(a) Be reachable, from the public Internet, in accordance with its A and/or AAAA records. This is a nonstarter for, say, a printer or switch.
(b) Be able to change a DNS record. This is doable if the device has outgoing Internet access and appropriate keys, but safely issuing those keys is not cleanly and uniformly possible across authoritative DNS servers. And there is nothing resembling a standard protocol to actually ask for the DNS-01 magic record to be installed. Do you really want every appliance to implement every plugin in this list:
https://eff-certbot.readthedocs.io/en/stable/using.html#dns-...
(c) Get some other agent to do (a) or (b) and issue the certificate to the device. Again, there is no standard here.
This could be SO much better if there was, for example:
(d) A complete, standard three-way protocol between the device that needs a certificate, the DNS provider, and the CA that would result, cleanly, in a certificate, and
(e) A fully standard way to do this with the help of a proxy that an communicate with the device, the DNS provider, and the CA, but without the device having any Internet access at all.
Then an administrator could set up a certificate proxy, enroll all their devices with the proxy, and get them certificates, with automatic renewal.
Right now, for a device to get a certificate via ACME, it needs to do one of:
(a) Be reachable, from the public Internet, in accordance with its A and/or AAAA records. This is a nonstarter for, say, a printer or switch.
(b) Be able to change a DNS record. This is doable if the device has outgoing Internet access and appropriate keys, but safely issuing those keys is not cleanly and uniformly possible across authoritative DNS servers. And there is nothing resembling a standard protocol to actually ask for the DNS-01 magic record to be installed. Do you really want every appliance to implement every plugin in this list:
https://eff-certbot.readthedocs.io/en/stable/using.html#dns-...
(c) Get some other agent to do (a) or (b) and issue the certificate to the device. Again, there is no standard here.
This could be SO much better if there was, for example:
(d) A complete, standard three-way protocol between the device that needs a certificate, the DNS provider, and the CA that would result, cleanly, in a certificate, and
(e) A fully standard way to do this with the help of a proxy that an communicate with the device, the DNS provider, and the CA, but without the device having any Internet access at all.
Then an administrator could set up a certificate proxy, enroll all their devices with the proxy, and get them certificates, with automatic renewal.
I think for (c), we have EPP: https://en.wikipedia.org/wiki/Extensible_Provisioning_Protoc... But I have never seen it in operation personally, having never worked for this kind of ISP.
For (b), I don't see why you couldn't install the required records using dynamic DNS, which is already widely implemented and deployed in other contexts. (It's the RFC 2136 item on the Certbot list.) It doesn't seem to be very commonly offered by DNS providers, though. It does work if you maintain the zone locally and use zone transfer (presumably with TSIG for authentication …) to publish to public DNS servers (if you don't want to run the public DNS servers yourself).
I think this space is a bit of a mess because no one is really expected to put this together themselves, rather they should get everything (mail hosting, web hosting, plus certificates) from a service provider. It's a wonder that grassroots participation is still possible at all.
For (b), I don't see why you couldn't install the required records using dynamic DNS, which is already widely implemented and deployed in other contexts. (It's the RFC 2136 item on the Certbot list.) It doesn't seem to be very commonly offered by DNS providers, though. It does work if you maintain the zone locally and use zone transfer (presumably with TSIG for authentication …) to publish to public DNS servers (if you don't want to run the public DNS servers yourself).
I think this space is a bit of a mess because no one is really expected to put this together themselves, rather they should get everything (mail hosting, web hosting, plus certificates) from a service provider. It's a wonder that grassroots participation is still possible at all.
Isn’t (a) solved by using an internal CA? I’m not seeing an immediate use case where something like an appliance is publicly addressable, but not at the A/AAA record.
(e) also sounds a lot like just running one of the existing certbot plugins on the proxy unless the appliance can’t be reverse proxied.
(e) also sounds a lot like just running one of the existing certbot plugins on the proxy unless the appliance can’t be reverse proxied.
Running an internal CA is maybe a good way to deal with networking hardware managed by only a few people, but it’s entirely useless if the goal is to access a device from a client that won’t trust the CA. Also, name-constrained CAs are not widely deployed, and non-name-constrained CAs are asking for trouble.
As for a proxy, how exactly would you deploy certificates, via proxy, automatically renewing, to, say, a network switch, two different brands of printer, a camera, and a pile of containers and VMs, all from different vendors? Sure, you can hack something up, but it will be a kludge and it will not scale.
As for a proxy, how exactly would you deploy certificates, via proxy, automatically renewing, to, say, a network switch, two different brands of printer, a camera, and a pile of containers and VMs, all from different vendors? Sure, you can hack something up, but it will be a kludge and it will not scale.
Internal CAs are a pain because enrolling new CAs is difficult, especially without device management. It can also interfere quite badly with product testing.
Technically, it's not required for anyone but you to validate ownership of names further down the DNS tree once you have shown control over the DNS tree further up. Maybe combine it with the public suffix list to discourage misuse by certain service providers.
Technically, it's not required for anyone but you to validate ownership of names further down the DNS tree once you have shown control over the DNS tree further up. Maybe combine it with the public suffix list to discourage misuse by certain service providers.
(a) Not everyone can afford to manage that
(e) They key point is that it needs to be standardized to the point of the vendors supporting it. As long as there is a general API (for example) on the device that I can point a plug-in to, it's fine, but AFAIK such a thing does not exist at this point in time.
Yeah, https for local network appliances has been basically a nonstarter for ages, with the browsers basically shouting down any proposal to enable it with "it's not secure enough", while the trivially-sniffable status quo trundles on just fine (and administering your own root CA is a non-trivial amount of work for those who are capable of it, as well as opens you up to further issues given most browsers ignore the scope of root certificates, so anything you trust on your machines you are trusting for all sites).
> Now people will have to log in every 45 days, so that’s much less likely.
They will not login every 45 days.
What they will do is install a self-signed cert and train users to click "Trust" the first time they go there. Code will be updated to simply have the verify flag set to false in the TLS API call.
There's lots of stuff out there that does not support ACME/SCEP/whatever, and will never have it, and ain't nobody got time for manual updates.
They will not login every 45 days.
What they will do is install a self-signed cert and train users to click "Trust" the first time they go there. Code will be updated to simply have the verify flag set to false in the TLS API call.
There's lots of stuff out there that does not support ACME/SCEP/whatever, and will never have it, and ain't nobody got time for manual updates.
can confirm. Was forced to do this at a previous job actually
> It’s short enough to force people to either automate cert renewal or at least have a plan for doing it manually.
It can also be a case of "we no longer support connections from macOS", due to them pulling shit like this.
It can also be a case of "we no longer support connections from macOS", due to them pulling shit like this.
If I can publish LE certs on IPMI and firewall, then there is no issue
I literally ran into a problem with this a few weeks ago. My son didn’t charge his phone for a few days. When he turned it back on, the clock was turned back a few days. He couldn’t change the time manually and he couldn’t sync the clock over WiFi due to apple’s cert not being valid yet. We had to put a SIM card in for a few minutes to get the correct time.
Why couldn't you change the time manually? Is that an Apple thing?
parental lock, which also couldn't be disabled due to unable to connect to apple. it was pretty entertaining.
it's entertaining to me that you imposed an unnecessary security restriction on your kid's phone which resulted in inoperability
Remember: the most secure device is a device that doesn't work at all.
Thank you SSL/TLS cert lifespan cuts for making this a reality.
Well done, everyone.
Thank you SSL/TLS cert lifespan cuts for making this a reality.
Well done, everyone.
I was just looking at my comments (which I can no longer edit :-/) and realized they're super/unreasonably mean towards the "sysadmins" from the article.
While yes there are lazy/incompetent sysadmins, there are also lazy/incompetent engineers, marketers, etc this is not a magic sysadmin only thing.
I suspect that in most of the places where their are sysadmins/IT depts in this situation, they've been trying to do something about this for years, while the management of the company has refused to provide the required support or funding for the work because it's not "necessary".
While yes there are lazy/incompetent sysadmins, there are also lazy/incompetent engineers, marketers, etc this is not a magic sysadmin only thing.
I suspect that in most of the places where their are sysadmins/IT depts in this situation, they've been trying to do something about this for years, while the management of the company has refused to provide the required support or funding for the work because it's not "necessary".
So a decade from now or so we'll reach the point of every request having its own cert?
There still is Kerberos. It has the advantage that it can run exclusively on top of symmetric encryption. You wouldn't get a key per request, but rather a shared secret for every user/service combination.
In case there is a cryptographic breakthrough and we can't be sure we can do asymmetric cryptography securely anymore, we'd have to switch to something like that anyway.
In case there is a cryptographic breakthrough and we can't be sure we can do asymmetric cryptography securely anymore, we'd have to switch to something like that anyway.
“Sysadmins rage against basic good practice as has been understood for more than a decade”
If you are unable to roll certificates within a few hours your systems are not set up properly, and you cannot respond appropriately to compromise. The problem with the constant push back of “oh it’s hard to manually perform a certificate update over our services” is fucking stupid and needs to stop. If you cannot roll your certificates regularly without a problem, then I sure as shit doubt you can update your systems in response to an actual urgent issue.
The problem is not onerous rules from Apple, the problem is you’ve spent decades complaining about it being too hard to do basic updates to your services and software, and then every time you get an extension to fix your broken ass systems you go “sweet” and don’t fix the fucking problem.
JFC the incompetence.
If you are unable to roll certificates within a few hours your systems are not set up properly, and you cannot respond appropriately to compromise. The problem with the constant push back of “oh it’s hard to manually perform a certificate update over our services” is fucking stupid and needs to stop. If you cannot roll your certificates regularly without a problem, then I sure as shit doubt you can update your systems in response to an actual urgent issue.
The problem is not onerous rules from Apple, the problem is you’ve spent decades complaining about it being too hard to do basic updates to your services and software, and then every time you get an extension to fix your broken ass systems you go “sweet” and don’t fix the fucking problem.
JFC the incompetence.
Knowing Apple, this will also affect certificates generated using your own SSL root and intermediates as well.
A very uncool thing to do when the application only gets updated about once a year. :(
A very uncool thing to do when the application only gets updated about once a year. :(
There's little evidence to support this afaict. Certs generated using non-default Roots are limited to 825 days in validity, more than twice the limit for those generated using the defautl roots.
90 minutes/seconds/ms or bust.
[dupe]
More discussion: https://news.ycombinator.com/item?id=41845885
More discussion: https://news.ycombinator.com/item?id=41845885