macOS Leaks Application Usage, Forces Apple to Make Hard Decisions

Last week, users of macOS noticed that attempting to open non-Apple applications while connected to the Internet resulted in long delays, if the applications opened at all. The interruptions were caused by a macOS security service attempting to reach Apple’s Online Certificate Status Protocol (OCSP) server, which had become unreachable due to internal errors. When security researchers looked into the contents of the OCSP requests, they found that these requests contained a hash of the developer’s certificate for the application that was being run, which was used by Apple in security checks.[1] The developer certificate contains a description of the individual, company, or organization which coded the application (e.g. Adobe or Tor Project), and thus leaks to Apple that an application by this developer was opened.

Moreover, OCSP requests are not encrypted. This means that any passive listener also learns which application a macOS user is opening and when.[2] Those with this attack capability include any upstream service provider of the user; Akamai, the ISP hosting Apple’s OCSP service; or any hacker on the same network as you when you connect to, say, your local coffee shop’s WiFi. A detailed explanation can be found in this article.

Part of the concern that accompanied this privacy leak was the exclusion of userspace applications like LittleSnitch from the ability to detect or block this traffic. Even if altering traffic to essential security services on macOS poses a risk, we encourage Apple to allow power users the ability to choose trusted applications to control where their traffic is sent.

Apple quickly announced a new encrypted protocol for checking developer certificates and that they would allow users to opt out of the security checks. However, these changes will not roll out until sometime next year. Developing a new protocol and implementing it in software is not an overnight process, so it would be unfair to hold Apple to an impossible standard.

But why has Apple not simply turned the OCSP requests off for now? To answer this question, we have to discuss what the OCSP developer certificate check actually does. It prevents unwanted or malicious software from being run on macOS machines. If Apple detects that a developer has shipped malware (either through theft of signing keys or malice), Apple can revoke that developer’s certificate. When macOS next opens that application, Apple’s OCSP server will respond to the request (through a system service called `trustd`) that the developer is no longer trusted. So the application doesn’t open, thus preventing the malware from being run.

Fixing this privacy leak, while maintaining the safety of applications by checking for developer certificate revocations through OCSP, is not as simple as fixing an ordinary bug in code. This is a structural bug, so it requires structural fixes. In this case, Apple faces a balancing act between user privacy and safety. A criticism can be made that they haven’t given users the option to weigh the dilemma on their own, and simply made the decision for them. This is a valid critique. But the inevitable response is equally valid: that users shouldn’t be forced to understand a difficult topic and its underlying trade-offs simply to use their machines.

Apple made a difficult choice to preserve user safety, but at the peril of their more privacy-focused users. macOS users who understand the risks and prefer privacy can take steps to block the OCSP requests. We recommend that users who do this set a reminder for themselves to restore these OCSP requests once Apple adds the ability to encrypt them.

[1] Initial reports of the failure claimed Apple was receiving hashes of the application itself, which would have been even worse, if it were true.

[2] Companies such as Adobe develop many different applications, so an attacker would be able to establish that the application being opened is one of the set of all applications that Adobe has signed for macOS. Tor, on the other hand, almost exclusively develops a single application for end-users: the Tor Browser. So an attacker observing the Tor developer certificate will be able to determine that Tor Browser is being opened, even if the user takes steps to obscure their traffic within the app.