Comment by loeg
4 years ago
The URL mentioned in sibling comments suggests this has to do with certificate revocation (OCSP): https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot...
I agree that breaking system availability when an OCSP server isn't available is user-hostile and unnecessary.
> 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.
If it were unreachable then the daemon would fail fast. A slowdown on the other hand just makes requests to the daemon queue up.
I am calling an unresponsive service unavailable. I think we agree about everything else.
What’s the alternative tho?
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).
This is exactly right, and given Apple’s privacy commitment should have been implemented already.
Publish revocations as security updates to the OS?
Security updates take too long. How bout each copy of MacOS keeps local copy of revocation database, and updates in background?
Much faster, updates relatively quickly, and not subject to network outages.
2 replies →
Microsoft Windows 10.
You don't need an alternative. The entire concept is totally unnecessary.
The alternative is OCSP being allowed if internet isn't available, which is a security risk for reasonable defense-in-depth strategies.
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.
If your Mac is unambiguously offline it fails open. What it's handling poorly is the fail-slow case.
2 replies →
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).
MacOS already fails-open if the OCSP server resolves to the local host (see: every suggestion to edit /etc/hosts in this discussion).