The cataclysm of the launch of Big Sur, with hanging installations, slowness of the system and applications that did not open quickly gave way to investigating what was happening and this investigation brought somewhat hasty conclusions that do not fit reality, which has given a weekend full of technical articles in one sense and another.
We will try to explain what happened
With the launch of macOS Big Sur on Thursday, Mac users began to have problems trying to open applications while connected to the internet. The system status pay at Apple attributed the situation to problems with the developer ID notarization system, and the developer Jeff Johnson determined it was a server issue OCSP from Apple.
What is OCSP
Remember that, from Mojave, Apple requires that for an application to be installed, it must be signed and registered with Apple, so that its authenticity can be verified. The part of macOS that handles this is called Gatekeeper, and you can find it in System Preferences.
Gatekeeper performs online checks to see if an app contains known malware and if the developer’s certificate is valid.
The acronym “OCSP” refers to Online Certificate Status Protocol stapling, or more briefly “certificate stapling.” Apple uses this certificate “stapling” to help streamline the process of having millions of Apple devices checking the validity of millions and millions of certificates every day.
As the name implies, it is used to verify the validity of a certificate without the need to download and scan long certificate revocation lists. macOS uses OCSP to ensure that the developer’s certificate has not been canceled before the application opens. (for example, this is what is done if someone tries to open Fortnite).
Apple’s notarization service is an automated system that scans the software for malicious content, checks the code signature, and quickly returns the result. If there are no problems, the notarization service generates a ticket to be attached to the software, and also publishes it online so that the Gatekeeper can find it.
What if the application cannot connect to the OCSP server
If an Apple device cannot connect to the network but you want to open an application, the validation of the certificate is supposed to “have a soft failure” (that is, it is canceled without notifying the user) so that, when it detects that can’t connect to the internet lets open the app anyway.
This process of connecting to Apple servers for notarization appears in the Console as
trustd—The name of the process in macOS responsible for checking with Apple’s servers if an app is “notarized”, and its mission is to connect to a domain called
So what happened?
The problem comes because the server never “crashed”. It kept receiving requests, but it was so extremely slow to process them that in the end they made a “timeout”, that is, they were canceled after a while, due to lack of response.
As the server did not hang, but continued to receive requests (the system knew that the server was still active because when performing a Lookup it obtained the correct DNS), the “soft failure” did not occur, but was waiting for a response, which caused the apps did not open and / or the whole system worked slow (so disconnecting from the internet solved the problem).
But aside from technical issues, this is about privacy and sending personal information to Apple.
That appears to have been a misinterpretation – or ignorance – of what was really going on with notarization. In reality, macOS sends opaque information about the developer’s certificate of the applications that you want to open, but not the application name (a developer uses the same certificate in all their applications) or the device ID. Source
macOS is 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 if the developer’s certificate has been canceled. 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 find out what each user is opening or using on their device.
The notarization checks are only to know that the app does not contain malware and is carried out through an encrypted connection that is prepared to overcome a server failure.
These security checks have never included the user’s Apple ID or the identity of their device. To further protect privacy, we have stopped including the IP address associated with the Developer ID certificate checks, and we will ensure that any IP addresses are removed from the logs 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.
Why carry that traffic using unencrypted requests?
It is common for OCSP to use HTTP, to avoid loops. If HTTPS is used to verify a certificate with OCSP then you would also have to verify the certificate of the HTTPS connection using OCSP. That would involve opening another HTTPS connection and so on.
Of course, although OCSP does not require encryption, the responses do need to be signed by the server.
The problems for Apple
Despite the fact that there is a technical explanation for the operation in unencrypted HTTP for this mechanism, and that the part of respect for privacy on the part of Apple has been quite clear, there are still two great shadows looming on this subject.
The first is, of course, the image problem, which again brings shadows of bygone eras when Apple seemed unable to foresee the demand for its products and the burden it would entail.
That the most valuable company in the world has a stumble of this size on the day of the launch of its new version of the operating system, which is so important that it has stopped being macOS X and starts to be called macOS 11, is something truly unheard of.
Sure, Apple isn’t the only one who miscalculates resources or has disastrous software deployments, but it’s the one that attracts the most eyes, and it’s too obvious a blush to turn a blind eye.
According the article that has raised the debate Apple has left a door open in the end-to-end closure of iMessage (Messages). Currently, iOS asks you to enter your Apple ID during setup, and it automatically enables iCloud backups and iCloud Backup.
iCloud Backup is not end-to-end encrypted – encrypts device backup with Apple keys. Any device with iCloud Backup enabled (it’s enabled by default) backs up the iMessage history to Apple servers, along with the device’s secret keys for iMessage, as soon as it connects to power to charge.
Apple can decrypt and read this information without even touching the device. Even if you have iCloud and / or iCloud Backup disabled: those you are messaging with probably don’t have it disabled, and your conversation is being uploaded to Apple (and, through PRISM, freely available to the intelligence community American, FBI and other friends, without having to ask for a warrant or have probable cause).
This certainly deserves some explanation from the company that puts the privacy of users first. Do not you think?