7

After the recent issue of trustd trying to connect to Apple's overloaded servers, and causing slowdowns to Macs around the world, one discussion page suggested a temporary fix:

This command in Terminal will edit your /etc/hosts file to block connections to the problematic Apple server:

echo 0.0.0.0 ocsp.apple.com | sudo tee -a /etc/hosts

It then said "you REALLY do not want to leave that line in /etc/hosts—it MUST come out later!".

Does anyone know what the consequences might be of obstructing trustd in this way long-term?

1
  • 1
    An adjacent question might be: would a user who is philosophically bothered by this check be better off with this host file block, or should they just disable Gatekeeper? Nov 13 '20 at 18:25
2

The OCSP protocol is used to check whether or not a certificate has been revoked. In this context, it is used to give Apple the opportunity to revoke the “blessing” it has given to a specific piece of software. This could happen for example for example if Apple discovers that it contains malware, or when the software developer turns out to be a scammer, or similar situations.

Blocking OCSP does not interrupt normal certificate validation. Your Mac will still be able to tell whether or not the software has at some point received the “blessing” from Apple that makes it pass validation. If you have non-signed software or software signed by someone else than Apple, this will still be picked up by the system.

Disabling OCSP access only means that software that Apple once validated won’t be subject to checks in the future to see if Apple decided to revoke that validation.

Whether or not that is sustainable for a longer period of time depends on your own threat assessment. For ordinary users, I would recommend not blocking OCSP, as it serves as an extra layer of protection against malicious software.

6

OCSP requests send a hash for every program you run, so that trustd can report the information (to a third-party CDN run by another company, Akamai). The purpose is to effectively verify whether the app that is launching is notarized or not by attempting to validate any Apple-related cryptographic certificates. With the release of macOS 11, we could no longer block certain Apple OS services with apps like Lulu and Little Snitch, as per the new restrictions to how third-party kernel extensions can function as well as to their scope of control. This feature was then removed with the release of macOS 11.2.

If you always know what you're installing and you trust the processes running on your Mac, there might not be an immediate consequence of blocking the OCSP requests. Since they require an internet connection, you could instead toggle your network connection to resolve any slow-downs the next time Apple's servers freeze up. If you want to block the OCSP requests, your solution should work (at least for that address). If you want to disable the service, you can try the following commands:

sudo defaults write /Library/Preferences/com.apple.security.revocation.plist OCSPStyle None
sudo defaults write com.apple.security.revocation.plist OCSPStyle None

I can't verify that it will make a difference, since Apple removed the conventional method to accomplish the equivalent in Keychain Access → Preferences years ago.

1
  • So those settings remove the ability to disable apps with revoked certs?
    – benwiggy
    Nov 14 '20 at 9:17
0

trustd handles the validation of certificates.

If you permanently block this, you will block the method for validating certificates used for a number of functions within the system from kext and app authenticity to certs in your keychain etc.

From the man page

trustd provides services for evaluating trust in certificates for all processes on the system.

8
  • 1
    Wonder what happens though. Will the system sooner or later realize this and stop working, or does it just increase the risk (if there is any) of running unvalidated applications?
    – nohillside
    Nov 13 '20 at 18:19
  • It will probably be like the HP printer drive issue that happened earlier but from an "age" perspective. After all, a computer can't always be connected to the internet so it may take a few days/weeks to throw an error.
    – Allan
    Nov 13 '20 at 18:22
  • And Apple even made it worse in Big Sur as applications like Little Snitch can't block such traffic any longer apple.slashdot.org/story/20/11/13/1726224/…
    – nohillside
    Nov 13 '20 at 18:27
  • 1
    I would guess that nothing happens long-term. I can't point to an explicit reference atm, but I've definitely seen Tweets of people saying they blocked ocsp.apple.com which far predate yesterday's incident. If it led to some type of timebomb, I'd expect to have read about it by now. Nov 13 '20 at 18:27
  • 2
    It will never fail, since signed applications are signed forever (the certificate used to sign it cannot be used forever, this is what the expiration date refers to). Your system is doing this to protect you from certificates that have been revoked, but there's no reason to believe it would ever refuse to open an application simply due to time passing. Nov 13 '20 at 19:19
-1

Happend to me that this service, on slow internet connection or login-required hotspot, whe the macbook wakes from stop condition just block the keyboard and trackpad, after having successfully blacklisted on the hosts file the problem goes away... so, even it is not a ocsp server problem, this service can slow your computer a lot waiting for every single hash to be received and validated.(Macbook pro 2019 13")

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .