Thursday, June 16, 2022

Apple Reneged on OCSP Privacy

Jeffrey Paul:

In the current version of macOS, Monterey, on every system update on a system containing an M1 chip, such as all the new shiny/fast ARM (“Apple Silicon”) macs, the update process phones home to Apple to obtain a special boot signature, known in Apple jargon as a “ticket”.

Jeff Johnson:

In response to the Mac OCSP appocalypse [with Big Sur], Apple promised several changes.


The first change was accomplished: macOS switched from using the unencrypted http service to the new encrypted https service.


The third change, a new preference for users to opt out, is still nowhere to be found, not even in the new macOS 13 Ventura beta. The System Preferences app itself has been redesigned and renamed on Ventura, yet the promised new preference is missing, more than a year and half after Apple made these promises.


Update (2022-06-17): See also: Hacker News.

4 Comments RSS · Twitter

My prediction: another year from now Apple finally implements the ability to opt out, but doing so needlessly and by design causes some essential part of the system to stop working completely, like iCloud or the app store or something.

(Have I become too cynical?)

@Bri anyone who wants privacy from Apple isn't using iCloud (effectively unencrypted) or the App Store. Why do privacy theater? If you want privacy, stop using Apple services in the first place. There are already levers in the OS for disabling iCloud and the App Store and the other phone-home.

I'd like to take this opportunity to point out that the App Fair app ( includes an "App Launch Privacy" preference that allows you to temporarily disable the OCSP lookup during app launch. This works both for apps that are launched via the App Fair app itself, as well as any other apps that you launch within the ALP window.

Yes, it is inexcusable that this information is transmitted in plaintext, but I feel like there should also be a conversation about the type of power this information grants Apple in the first place.

My understanding from reading the documentation and HN threads is that with Full Security enabled, ARM Macs will only run a macOS build that's been signed for that individual machine. It's also my understanding that this approach has been in place for quite a while on iOS devices.

While this approach is great for its intended purpose (preventing rollback attacks), this also means that if one is signed into iCloud on an ARM Mac or iDevice, the ECID can be used by Apple to target individual users should they wish. I would feel better about this situation if I could verify that my personalized copy of macOS/iOS has the same bits as everyone else, but I am not aware of such a method.

This built-in ability of Apple to send individualized OS builds has the potential for all manner of abuse, whether government-ordered or at Apple's own initiative. I feel like the only check on Apple's behavior is potential civil liability and loss of trust should such abuse take place and become public.

Even if one wanted to dismiss the possibility of compelled behavior or nefarious intent on Apple's part, there is the matter of bugs. We know from the steady stream of security updates that client-side Apple software ships with a lot of vulnerabilities, many of which are discovered only through the efforts of third parties. However, security researchers do not get access to Apple's servers, nor do we get public disclosure of any server-side security vulnerabilities in the infrastructure that powers Apple ID, iCloud, OCSP, the Developer ID CA, Notarization, XProtect, or Apple's 1st party signing servers for their OSes and apps.

Given the critical role that Apple's infrastructure plays in this chain of trust, it seems reasonable for Apple to establish and maintain this trust by 1) publicly disclosing server-side vulnerabilities/patches and 2) allowing rolling audits of 1st-party OS, app, and server software by at least one independent 3rd party.

Leave a Comment