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, @09:15PM (4 children)
Why would I be directly connecting to a LAN IP address in my browser in the library or coffee shop? I mean, literally entering in http://192.168.1.44 [192.168.1.44] into the firefox address bar ? Where do you envision this scenario coming up exactly? (PS If you are using DNS, then you need a valid cert -- I'm only excepting direct local IP addresses here.)
We're kind of chasing the wrong problem here. First, I did say that I think in this case the browser should still properly warn you about certificates; it should just be less obnoxious about blocking you if its a LAN connection by IP address. So you would still get a warning at the coffee shop.
And second, remember certs solve two problems:
1) the connection between me and the host is encrypted; so it can't be listened in on by other devices.
self-signed certs satisfy that.
2) I am actually talking to the host I think I am talking to.
If i connect to login.mybank.com; I want to be sure that the computer I'm talking to really is login.mybank.com; and not some other device pretending to be login.mybank.com. A self signed cert fails that, because anyone can self-sign their claim that the host is login.mybank.com. And the whole public signed certificate chain to a trusted root is just to allow me to assert that I trust that only the proper owner of mybank.com can get such properly signed certificates for login.mybank.com; so if this computer has a valid certificate chain, then I trust that it is properly authorized by the owner of mybank.com and it is the computer i think it is.
But if I am connecting to 192.168.1.44; that's not even a name. As long as the device responding is really sending traffic from IP address 192.168.1.44 (which can be verified), then don't I properly know I am talking to the device I asked to talk to?
(Score: 2) by Pino P on Tuesday February 25 2020, @09:58PM (3 children)
Then why does multicast DNS (mDNS) even exist, given that other protocols have changed to make the names it issues unusable?
Nested NATs mean that a device that reports itself as 192.168.1.44 and is in the same room as you might not actually be 192.168.1.44 on your network but instead 192.168.1.44 on a different network.
(Score: 2) by vux984 on Tuesday February 25 2020, @10:29PM (2 children)
"Then why does multicast DNS (mDNS) even exist"
How is that a rebuttal? If you want trust you can't rely on a zero-configuration service that doesn't offer any guarantees.
"Nested NATs mean that a device that reports itself as 192.168.1.44 and is in the same room as you might not actually be 192.168.1.44 on your network but instead 192.168.1.44 on a different network."
Nevertheless I am talking to a device at 192.168.1.44 on the LAN, and that's what i asked the browser to do. That its not THE device i think it is, is on me. LAN IP Addresses are not globally unique. If tell the browser to talk to the device on the LAN at 192.168.1.44 as long as its doing _that_ its done its job the best that can be reasonably expected. Putting certificates on things isn't going to fix it. 192.168.1.44 is still not going to go to the device I thought it was going to; it'll just go to the wrong device with a certificate on it. That's the inherent *risk i take* for using a LAN IP address instead of a FQDN.
(Score: 2) by Pino P on Wednesday February 26 2020, @02:22PM (1 child)
Over the past few years, web browser publishers have begun "deprecating" (Mozilla's word) protocols that do not provide trust [mozilla.org]. Thus as time goes on, "a zero-configuration service that doesn't offer any guarantees" becomes less and less useful.
Hence why the browser does not trust it.
So what's a good way to mitigate such risks for non-technical users, who happen to outnumber the sort of highly technical users who frequent SoylentNews?
(Score: 2) by vux984 on Wednesday February 26 2020, @04:16PM
The point remains that connecting to LAN devices by LAN ip addresses its comparatively low pretty low risk scenario *in the first place*.