Comment by alwillis
4 years ago
Welcome to 2020.
Because we can't have nice things, Apple has to check that apps are signed with a current certificate for safety and security reasons. OCSP tells the client if the certificate has been revoked or not.
Try opening a non-https web page; you'll get a bunch of ominous warnings from all major browsers.
Browser certificates need to be OSCP signed for the browser to trust them. You can't even get a new cert if the issuer’s OCSP server goes down, which does happen on occasion.
There are so many dependencies to ensure we're not running malware infected apps that sometimes things break.
Let’s not get carried away; every major tech company has had some version of this happen at one time or another.
FWIW, I haven't experienced any issues with my iMac running Big Sur running Apple or 3rd party apps all day.
This used to be true, but neither Chrome nor Firefox actually check CRLs or OCSP that much. They'll accept OCSP-stapling, but that's about it.
This is a very serious concern for Enterprise PKI systems: revoking certificates is now virtually impossible. CRLs and OCSP do practically nothing.
Google especially has unilaterally decided that Enterprise PKI systems don't matter. They have established a new "standard" called Certificate Transparency, which they use to make CRLSets that they publish as Chrome updates.
Which is fine I suppose for public CAs, but utterly useless on internal-use private CAs on local networks, especially those with lots of BYOD or guest/partner systems. Think universities or hospitals.
Google has become a juggernaut with more control over computing in general (not even just the Internet!) than all of the world governments put together.
They're getting truly terrifying.
It's a shame you're being downvoted as you're right, CRLs and OCSP do practically nothing _for webbrowsers_
OSCP is flawed because you can block the connection, meaning
1) Your browswer has to accept it (thus an attacker feeding you the bad certificate can bypass OSCP)
2) Your browswer blocks completely (thus DOSsing all connections), and people use another browser
CRLs don't scale - you can't keep a cached list of every revoked cert globally.
However I pull down the CRLs for my internal CA every few hours onto my internal https sites, which rely on a client presenting a valid certificate to connect. If that doesn't get pulled down, I get a warning about it in the monitoring system. When a client with a client certificate connects, I check against my local cache of the CRL, and if it's been revoked, it can't connect.
What problem do you have on your private CA internal network that CRLs fix but browsers don't? Are you that concerned that your server certificates get compromised? You should be working to massively reduce the time those certificate are valid.
Firefox has historically checked OCSP by default everywhere but for Firefox mobile, where it was only checked for EV certs.
With the introduction of CRLite, the default is disabled, but those using Firefox with internal-use private CAs on local networks can renable via preferences, which can also be controlled by enterprise policies and tooling.
https://cloud.google.com/docs/chrome-enterprise/policies/?po...
This is all true; OCSP-stapling is the thing these days.
But these browsers won't trust a cert if it can't be found a Certificate Transparency log. Yes, a cert should be in at least two of them but if there's a networking problem or infrastructure issue, you're SOL.