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 Wednesday February 26 2020, @08:50PM (5 children)
We are in complete agreement on that, and on Chrome vs localhost too.
Although firefox "developer edition" seems to exist precisely to help alleviate some of this stuff; but of course checking the ink level and changing the network settings on your laser printer aren't "developer tasks". But maybe that's the direction this should go in... chrome for the internet, some chrome-derived fork that has all those restrictions toned down/turned off but it not an internet browser, and it *won't* browse the public internet. Good only for managing local devices and local development, troubleshooting your intranet, connecting to your router, etc. Call it LAN-Browser or something.
You click a link on your laser printer web tool that wants to go to supplies.brother.com and it opens that link in a new window in chrome.
Your local computer & local LAN, and the internet are *not* the same thing. Maybe instead of different settings and security sets for different zones it would simply be better to simply use different applications.
(Score: 2) by sjames on Wednesday February 26 2020, @09:49PM (4 children)
That too might break a number of perfectly reasonable use cases. For example, what if I'm using IPv6 and my LAN is using addresses that could be public but are filtered by my firewall? You as a mere mortal developer simply cannot know.
What is really needed is a way for the user to decide what's OK and what is not. I have no doubt that some people might make bad decisions, but that's the nature of things when you treat adults as adults. Either we accept that it's possible some idiot might toast a shotgun shell or we treat everyone like they're 5 years old and refuse to toast anything but manufacturer approved standard slices of white bread.
How about if something looks like it could be a problem, ask the user and accept their decision? Make sure their choice can be case by case rather than a choice between never for anything or always for everything.
Browsers USED to make it easy to look at the cert, then decide between reject it, accept it just this once, or accept it from now on. It was simple enough to do that you could talk your mom through it if necessary but it would be hard to do it accidentally.
(Score: 2) by vux984 on Wednesday February 26 2020, @10:26PM (3 children)
"For example, what if I'm using IPv6 and my LAN is using addresses that could be public but are filtered by my firewall? You as a mere mortal developer simply cannot know."
My computer knows which hosts are on the LAN and which aren't.
Now if you've got a complicated intranet with routed subnets using public address space, and you want to connect to devices using direct IPV6 addresses on different subnets within the intranet ... shit... your not a regular user. If you made that mess, then you'll figure something out ... throw a secure raspberry pi in each subnet to proxy for you, or setup a VPN, or edit the lan-browser configuration to add your private subnet ranges to the list of "private" ip ranges, and get that updated config signed by a trusted root cert for your organization... same as we trust self-signed/domain joined systems etc. Regular Home users aren't going to be hit by this.
Because (most) users always click "Accept". Few understand the message, and most don't even read it. They just click around until it "works".
Once she's done it a few times, and she's "trained" to do it, then she does it every time. Her laser printer toner status... her bank account phishing email redirecting to a fake site --> Same browser application, same warning message, same solution. The whole reason we don't do this anymore is that regular users consistently get it wrong. Not occasionally get it wrong. Not sometimes get it wrong. CONSISTENTLY GET IT WRONG.
(Score: 2) by sjames on Thursday February 27 2020, @02:06AM (2 children)
Then you should set the config option "child safe" on your mom's browser. If you click the button that says not recommended right on it without knowing what you're doing, you are the architect of your own problem. Kinda like when people use tape to hold the safety down on their lawnmower.
The whole IPv6 thing was simply the first thing that came to my mind you had failed to anticipate that would break things. Your proposed solution is already fairly complex and involved config options you hadn't recognized a need for. Are you sure there aren't a thousand more perfectly reasonable cases neither you nor I have thought of, each requiring more special case configurations?
As far as phishing goes, when I am running a pentest, I just use http to dodge the whole issue. Simple workarounds like that are often easier to implement for scams than they are for legitimate use cases meant to actually be secure.
You might be interested to know that a number of Cisco products will proxy ARP any reachable address on the other side, including the entire internet. I say that to drive home the point that there's just too much out there to smugly implement policy in software rather than sticking to mechanism and leaving policy to the user.
(Score: 2) by vux984 on Thursday February 27 2020, @05:52PM (1 child)
What are people supposed to do that don't have you around to manage their network for them? Meanwhile the printer's chat support will simply tell her to turn off child-safe mode, same as they currently instruct you to 'continue anyway' past the bad cert.
Agreed. But "blame the user" isn't a solution. And it's a bad software design pattern to ask end-users questions they aren't likely to know the answer to; especially security related questions, or to ask them "are they sure?" all day.
I'm aware, and im not sure how that changes anything. I even alluded to it as a potential solution for the ipv6 private routed intranet question.
The point remains, there is almost never a good reason for an *end user* to bypass an expired cert to reach an internet FQDN. There are LOTS of good reasons for end users to bypass expired certs on the LAN. So its an improvement over the status quo. **Even** if its not perfect, it reduces the attack surface, and reduces the number of useless warnings users get.
Sure if a malicious actor has control of your LAN router, and of your localhost lan ip configuration so that it can trick your host into thinking address X is on the LAN, and then they get you to enter that host's IP address directly into the address bar of your browser, so it can arp proxy the packets to an internet host ... then you are so totally pwned anyway that nothing was going to save you.
(Score: 2) by sjames on Thursday February 27 2020, @11:07PM
It's better than Nerfing the world. Better yet, educate the user (No means No) then hope for the best.