As Apple launched its new macOS operating system to the public yesterday, serious server outages occurred that saw widespread Big Sur download/install failures, iMessage and Apple Pay go down but more than that, even performance issues for users running macOS Catalina and earlier. We learned why that happened at a high-level yesterday, now security researcher Jeffry Paul has shared a deep-dive of his understanding along with his privacy and security concerns for Macs, especially Apple Silicon ones.
Update: Apple has shared a response to Paul’s concerns in an updated support document that includes what macOS does to protect your privacy and security, and three new steps it will take in the future for greater privacy and flexibility.
Update 11/15 8:25 pm PT: Apple has updated a Mac security and privacy support document today sharing details about Gatekeeper and the OCSP process. Importantly, Apple highlights it doesn’t mix data from the process of checking apps for malware with any information about Apple users and doesn’t use the app notarization process to know what apps users are running.
The company also details Apple IDs and device identification have never been involved with these software security checks.
But going forward “over the next year,” Apple will be making some changes to offer more security and flexibility for Macs. First is that Apple will stop logging IP addresses during the process of checking app notarizations.
Second, it’s putting in place new protections to prevent server failure issues. And finally, addressing the overarching concern that Jeffry Paul raised, Apple will release an update to allow users to opt-out of using these macOS security protections.
We’ve also learned more technical details about how this all works from Apple that aligns with what independent security researcher Jacopo Jannone shared earlier.
Privacy protections
macOS has been designed to keep users and their data safe while respecting their privacy.Gatekeeper performs online checks to verify if an app contains known malware and whether the developer’s signing certificate is revoked. We have never combined data from these checks with information about Apple users or their devices. We do not use data from these checks to learn what individual users are launching or running on their devices.
Notarization checks if the app contains known malware using an encrypted connection that is resilient to server failures.
These security checks have never included the user’s Apple ID or the identity of their device. To further protect privacy, we have stopped logging IP addresses associated with Developer ID certificate checks, and we will ensure that any collected IP addresses are removed from logs.
In addition, over the next year we will introduce several changes to our security checks:
A new encrypted protocol for Developer ID certificate revocation checksStrong protections against server failure*A new preference for users to opt out of these security protections
macOS’ process of using OCSP is a very important security measure to prevent malicious software from running on Macs. It checks to see if a Developer ID certificate used by an app has been revoked due to software being compromised or events like a dev certificate being used to sign malicious software.
Online certificate status protocol (OCSP) is used industry-wide and the reason why it works over unencrypted HTTP connections is that it is used to check more than just software certificates, like web connection encryption certificates. If HTTPS were used, it would create an endless loop. Jannone explained it succinctly: “If you used HTTPS for checking a certificate with OCSP then you would need to also check the certificate for the HTTPS connection using OCSP. That would imply opening another HTTPS connection and so on.”
Two notable points on this are that it’s not strange for macOS to be using unencrypted requests for this as that’s the industry standard and that with Apple’s commitment to security and privacy, it is investing in creating a new, encrypted protocol that goes above and beyond OCSP.
In addition to the OCSP process currently used by Apple, macOS Catalina and later also have another process where all apps are notarized by Apple after having checked for malware. When launching an app, macOS makes another check to make certain the app hasn’t become malicious since the first notarization. This process is encrypted, isn’t usually impacted by server issues, and indeed wasn’t affected by the OCSP issue.
As for the performance problems we saw on macOS Catalina and earlier during Apple’s server issues last week, they were caused by a server-side misconfiguration that was exacerbated by an unrelated CDN misconfiguration. Those issues were resolved on Apple’s end a few hours after they began with no action needed to be done on the users’ part.
Between the explanation of how everything is working here and the commitment to the future changes described above, Apple shows it is listening to users and putting privacy and security first.
Update 11/15 9:00 am PT: More details about Apple’s use of OCSP have been shared by cybersecurity researcher Jacopo Jannone. He says that macOS isn’t sending a hash of each app to Apple when they run and explains why the industry-standard OCSP doesn’t use encryption. Further, he says Paul’s analysis “isn’t quite accurate” and importantly notes that Apple uses this process to check and prevent apps with malware from running on your Mac. Read more from Jannone here.
Original post: Not long after macOS Big Sur officially launched for all users, we started seeing reports of extremely slow download times, download failures, and in the cases that the download did go through, an error at the end that prevented installation.
At the same time, we saw Apple’s Developer website go down, followed by outages for iMessage, Apple Maps, Apple Pay, Apple Card, and some Developer services. Then the reports flooded in about third-party apps on Macs running Catalina and earlier not launching or hanging and other sluggish performance.
- Here are the latest details on Apple outages affecting Mac apps, Big Sur updates, iMessage, and more
Developer Jeff Johnson was one of the first to point out what was going on: an issue with Macs connecting to an Apple server: OCSP. Then developer Panic elaborated that it had to do with Apple’s Gatekeeper feature checking for app validity.
Now security researcher and hacker Jeffry Paul has published an in-depth look at what he saw happen and his related privacy and security concerns in his post “Your Computer Isn’t Yours.”
He goes on to explain what Apple sees from the process:
On modern versions of macOS, you simply can’t power on your computer, launch a text editor or eBook reader, and write or read, without a log of your activity being transmitted and stored.
It turns out that in the current version of the macOS, the OS sends to Apple a hash (unique identifier) of each and every program you run, when you run it. Lots of people didn’t realize this, because it’s silent and invisible and it fails instantly and gracefully when you’re offline, but today the server got really slow and it didn’t hit the fail-fast code path, and everyone’s apps failed to open if they were connected to the internet.
Paul continues by posing the argument many readers might be thinking: “Who cares?” He answers that by explaining that OCSP requests are unencrypted and it’s not just Apple who has access to the data:
Because it does this using the internet, the server sees your IP, of course, and knows what time the request came in. An IP address allows for coarse, city-level and ISP-level geolocation, and allows for a table that has the following headings:
Date, Time, Computer, ISP, City, State, Application Hash
This means that Apple knows when you’re at home. When you’re at work. What apps you open there, and how often. They know when you open Premiere over at a friend’s house on their Wi-Fi, and they know when you open Tor Browser in a hotel on a trip to another city.
Paul mentions some workarounds to prevent this tracking but highlights that those may be gone with macOS Big Sur.
These OCSP requests are transmitted unencrypted. Everyone who can see the network can see these, including your ISP and anyone who has tapped their cables.
These requests go to a third-party CDN run by another company, Akamai.
Since October of 2012, Apple is a partner in the US military intelligence community’s PRISM spying program, which grants the US federal police and military unfettered access to this data without a warrant, any time they ask for it. In the first half of 2019 they did this over 18,000 times, and another 17,500+ times in the second half of 2019.
This data amounts to a tremendous trove of data about your life and habits, and allows someone possessing all of it to identify your movement and activity patterns. For some people, this can even pose a physical danger to them.
Paul highlights that Apple’s new M1-powered Macs won’t run anything earlier than macOS Big Sur and says it’s a choice:
Now, it’s been possible up until today to block this sort of stuff on your Mac using a program called Little Snitch (really, the only thing keeping me using macOS at this point). In the default configuration, it blanket allows all of this computer-to-Apple communication, but you can disable those default rules and go on to approve or deny each of these connections, and your computer will continue to work fine without snitching on you to Apple.
The version of macOS that was released today, 11.0, also known as Big Sur, has new APIs that prevent Little Snitch from working the same way. The new APIs don’t permit Little Snitch to inspect or block any OS level processes. Additionally, the new rules in macOS 11 even hobble VPNs so that Apple apps will simply bypass them.
@patrickwardle lets us know that trustd, the daemon responsible for these requests, is in the new ContentFilterExclusionList in macOS 11, which means it can’t be blocked by any user-controlled firewall or VPN. In his screenshot, it also shows that CommCenter (used for making phone calls from your Mac) and Maps will also leak past your firewall/VPN, potentially compromising your voice traffic and future/planned location information.
He updated the post to share that there may be a workaround via the bputil tool but that he’ll need to test it to confirm that.
you can have a fast and efficient machine, or you can have a private one. (Apple mobile devices have already been this way for several years.) Short of using an external network filtering device like a travel/vpn router that you can totally control, there will be no way to boot any OS on the new Apple Silicon macs that won’t phone home, and you can’t modify the OS to prevent this (or they won’t boot at all, due to hardware-based cryptographic protections).
In closing, Paul says “your computer now serves a remote master, who has decided that they are entitled to spy on you.
Apple holds privacy and security as some of its core beliefs, so we’ll have to wait and hear what the company says about the concerns Paul has raised. We’ve reached out to Apple for comment and will update this post with any updates.
You can find the full article by Jeffry Paul here.
