SoylentNews is people
SoylentNews
from the honestly,-it's-for-your-own-good... dept.
Safari will, later this year, no longer accept new HTTPS certificates that expire more than 13 months from their creation date. That means websites using long-life SSL/TLS certs issued after the cut-off point will throw up privacy errors in Apple's browser.
The policy was unveiled by the iGiant at a Certification Authority Browser Forum (CA/Browser) meeting on Wednesday. Specifically, according to those present at the confab, from September 1, any new website cert valid for more than 398 days will not be trusted by the Safari browser and instead rejected. Older certs, issued prior to the deadline, are unaffected by this rule.
By implementing the policy in Safari, Apple will, by extension, enforce it on all iOS and macOS devices. This will put pressure on website admins and developers to make sure their certs meet Apple's requirements – or risk breaking pages on a billion-plus devices and computers.
[...] Shortening the lifespan of certificates does come with some drawbacks. It has been noted that by increasing the frequency of certificate replacements, Apple and others are also making life a little more complicated for site owners and businesses that have to manage the certificates and compliance.
"Companies need to look to automation to assist with certificate deployment, renewal, and lifecycle management to reduce human overhead and the risk of error as the frequency of certificate replacement increase," Callan told us.
We note Let's Encrypt issues free HTTPS certificates that expire after 90 days, and provides tools to automate renewals, so those will be just fine – and they are used all over the web now. El Reg's cert is a year-long affair so we'll be OK.
GitHub.com uses a two-year certificate, which would fall foul of Apple's rules though it was issued before the cut-off deadline. However, it is due to be renewed by June, so there's plenty of opportunity to sort that out. Apple's website has a year-long HTTPS cert that needs renewing in October.
Microsoft is an interesting one: its dot-com's cert is a two-year affair, which expires in October. If Redmond renews it for another two years, it'll trip up over Safari's policy.
(Score: 2) by vux984 on Tuesday February 25 2020, @02:33AM
I agree, but nobody suggested that changing passwords is a solution to a weak hashing algorithm.
I'd say it protects against the known. That is -- I *know* lots of users are fuckwits. :)
As someone whose done IT I've been given countless passwords and access to all kinds of things in my role of fixing them or working on them that I didn't want or need, and certainly didn't need persistent access. Where they should have entered their password and let me drive as you aid, or setup a temporary access and then revoked it, but they didn't want to stick around or bother with that so they just left it behind on a note or by email. You can't fix stupid, and sometimes (oftentimes) they're the boss.
Periodically forcing a rotation at least sunsets some of the illicit access that's enabled by this poor password hygiene.
There's nothing I could do to change their behavior, but at least periodically forcing them to rotate them meant that at least just the current secretary and IT consultants likely had access instead of everyone who had ever worked for the company.
The problem isn't generally that the technology to solve this doesn't exist, merely that people refuse to use it, or that there are many places where it hasn't been implemented. There are lots of things that do not offer options. Quickbooks Pro only has one "admin" account, countless devices and services are likewise setup like that. So if multiple people need to share the admin account they have to share that password. Forcing a rotation now and again helps to "reset" who still has access to those resources.