> I agree that breaking system availability when an OCSP server isn't available is user-hostile and unnecessary.
Based on the OP tweet... depending on the way it is unavailable, the failure is indeed ignored in some cases. "Denying that connection fixes it, because OCSP is a soft failure (Disconnect internet also fixes.)"
So it may be an actual unintended bug that a particular failure path results in a DoS instead?
Normally if there's no internet Gatekeeper instead checks the "stapled" notarization ticket from the notarization process. But since there is internet, and the ocsp server is technically "up" gatekeeper isn't checking the tickets.
actually I think the problem is not that it is not available, heck /etc/hosts fixes wouldn't work than. it's that it is unresponsive as hell, and they have no system wide circuit breaker, if it is slow.
A limited change would be to fail-open more of the time, e.g., if the OCSP server does not respond within a few milliseconds. (MacOS already fails-open in some internet scenarios.)
A better option is to asynchronously update a Certificate Revocation List ("CRL") and perform any check local to the machine. This avoids disclosing to Apple every single time you run a program, which program it is, and what network you're on. It could also emergency-revoke certificates just as quickly as the OCSP design by polling at the same frequency (every app startup).
I'd imagine that revocations don't happen often. And when they do, Apple has a perfectly capable infrastructure to push those small incremental changes on demand. It's almost as if they intentionally ignored such superior solution and chose calling home for other reasons...
Most OSCP implementations fail-open, not fail-closed. I get the benefits of having it fail-closed, but it should be opt in, because having an always-online requirement for using a mac is ridiculous.
Most browser vendors agree because they all stopped checking CRLs (like they technically should) when verifying certs.
I don’t think the design is wrong, I just think it’s tuned a little too cautious. If you’re going to verify certs then checking the CRL is something you really should do before approval. And you can’t sync the database entirely because it’s too big.
There really aren’t any good solutions to this unless you can solve the cache invalidation problem.
The OP literally says if you disallow connection or unplug the intenret it does fail open.
I think it's probably an unintended bug that this failure mode was fail-closed.
The costs of this unintended bug are going to be huge to Apple's reputation, as demonstrated in this whole HN thread, where many assuming what's going on is even WORSE than it really is.
(Personally I think having signed certs (with opt-in ability to run unsigned apps, as MacOS has) is fine. And fail-open OSCP revocation check is also fine-ish, although it would annoy me if it's making it slower to launch apps on the regular. The problem here is a bug, not one of design. But most of this thread is assuming Apple was doing something different than this. Of course, how often a company produces fairly catastrophic bugs is also on them).
I agree that breaking system availability when an OCSP server isn't available is user-hostile and unnecessary.