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: 5, Interesting) by sjames on Tuesday February 25 2020, @12:32AM (7 children)
If Apple and Google were actually serious about cert security, they would actually implement revocation.
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @03:11AM (6 children)
No argument there. But even so CRLs can be huge, as they need to contain every non-expired certificate that has been revoked, which can slow down browsers as they have to wait to download the whole thing. OCSP is also a privacy concern, as now the CAs know every time you check a website, and is subject to replay attacks. Both of them also suffer from what should happen if the CRL or OCSP server is unavailable and no cached copy exists.
Just like many standards, revocation fell to the side for many reasons, chief among them being the need for speed.
(Score: 3, Informative) by Pino P on Tuesday February 25 2020, @04:17AM (5 children)
Not if the web server checks the OCSP responder (say) once an hour, retrieves a response signed and timestamped by the CA, caches it, and includes it with the server's certificate whenever the client makes a connection. This is called OCSP stapling [cloudflare.com].
How so, given that responses are timestamped and expire promptly?
Likewise if the DNS server goes down or the origin web server goes down.
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @05:57AM (4 children)
You should check the stats for how many websites actually do OCSP stapling, it is the hundredths of a percent. Which means that if you do OCSP at all, you will be making the request yourself to the address in the certificate.
OCSP itself (including stapled ones) are vulnerable to replay attacks because the default OCSP interval for most providers is 7 days, with some going into multiple weeks (the last time I checked) and most web servers use the OCSP TTL for their cache length as well. For a non-stapled OCSP response, MITM only needs to get a single response, as the vast majority of CAs' servers do not honor the optional nonce value in the request and stapled responses don't use a per-client nonce anyway, which means everyone gets the same response. In addition, unless you "must-staple," it is a soft fail anyway.
And, unlike a DNS or web server problem, which admins are aware of and usually somewhat control themselves, CRL and OCSP servers are run by the CAs. You have no control over their availability or redundancy. If your DNS goes down, you can propagate changes over the NS network or have redundant providers in the first place. Your web server goes down, you can spin up a new one or have redundancy in the first place. Your CA has an outage, then there is literally nothing you can do about it. And that is if you are made aware of the problem at all.
(Score: 3, Interesting) by driverless on Tuesday February 25 2020, @10:56AM
CAs don't have redundancy, they have reduncandy. They're only as reliable as the least secure subsystem, and a failure in any of the many brittle parts will take you down with it.
(Score: 2) by driverless on Tuesday February 25 2020, @10:58AM
It's not the vast majority, per a survey carried out a few years ago no public CA honours the nonce. In other words every CA trusted by your browser is vulnerable to a replay attack because they completely ignore the nonce that's present to prevent the attack.
(Score: 2) by Pino P on Tuesday February 25 2020, @02:49PM (1 child)
Source please. The article I linked above ("High-reliability OCSP stapling and why it matters" by Nick Sullivan [cloudflare.com]) states that sites that use Cloudflare have been stapling since 2016 when Cloudflare introduced proactive fetching of OCSP responses as they near the typical 7-day expiration window.
What incidents have been reported of unexpired OCSP responses being used to forge connections on a recently revoked certificate?
Unless the VPS provider is having an outage. For example, an SSD outage on Google Compute Engine in December 2019 [google.com] brought down the Discord chat service [discordapp.com] among other sites.
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @10:58PM
https://www.ssllabs.com/ssl-pulse/ [ssllabs.com] shows that around 32.6% currently staple at all. According to censys, 190,921 certificates must-staple [censys.io] and 446,079,247 certificates don't [censys.io]. Even if the number were tilted so that the must-staple ones had 999 SANs and the "non-must-staple" had zero, then at best less than 30% of the domain names would be must-staple. A more reasonable number on either end of that for SANs just makes the percentage of must-staple sites worse.
It is a theoretical vulnerability, you asked how it was possible which two people explained. Even if there was an incident where it occurred, it may not be reported or widely publicized. But that doesn't change the fact that such a theoretical vulnerability exists, especially against those MITMed by someone or other situations.
And yes, lots of things can have outages, but an OCSP failure is not one of those you can plan for, work around, or have redundancy over (unlike your VPS example) without having multiple certificates from different providers spread around your infrastructure in advance or ready to go. And again, that is if you even notice the problem in the first place.