The Big Sur launch cataclysm, with suspended installations, system slowness and applications not opening quickly, gave way to investigating what was happening and this investigation led to somewhat hasty conclusions that did not conform to reality. which has given a full of technical articles in one direction and another.
We will try to explain what happened
With the launch of macOS Big Sur on Thursday, Mac users started having trouble trying to open applications while connected to the internet. The system state pay at Apple attributed the situation to problems with the developer ID notarization system, and developer Jeff Johnson determined that these were problems with Apple's OCSP server.
What is OCSP
https://twitter.com/lapcatsoftware/status/1326990296412991489?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1326990296412991489%7Ctwgr%5E%2Fiderf_url? e-perché-apple-non-lascia-che-accada-di nuovo?
Remember that, since Mojave, Apple requires that an application to be installed, 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 certificate is valid.
The acronym “OCSP” refers to the stapling of the online certificate status protocol or, more briefly, to the “stapling of the certificate”. Apple uses this “staple” certificate to help simplify the process of having millions of Apple devices checking the validity of millions upon millions of certificates every day.
As the name suggests, it is used to check the validity of a certificate without the need to download and scan long certificate revocation lists. macOS uses OCSP to make sure the developer certificate was not canceled before the app was opened. (for example, this is what is done if someone tries to open Fortnite).
Apple's Notarization Service is an automated system that scans software for malicious content, checks code signing, and quickly returns the result. If there are no problems, the notarization service generates a ticket to attach to the software, and also publishes it online so that the Gatekeeper can find it.
What happens if the application fails to connect to the OCSP server?
If an Apple device fails to connect to the network but you want to open an application, the certificate validation should "have a software error" (that is, it is canceled without notifying the user) so that when it detects that I cannot connect to the Internet, we open the app anyway.
That process of connecting to Apple's servers for authentication appears in the Console as trustd - the name of the process in macOS responsible for checking with Apple's servers whether an app is "authenticated" and its mission is to connect to a domain called ocsp.apple.com.
So what happened?
The problem arises because the server has never "stopped". It continued to receive requests, but was so slow in processing them that they eventually "time out", meaning they were canceled after a while, due to lack of response.
Since the server did not crash, but continued to receive requests (the system knew that the server was still active because it obtained the correct DNS while performing a search), the "soft failure" did not occur, but it was rather waiting for a response, which caused the apps not to open and / or the whole system was running slow (so disconnecting from the internet solved the problem).
But technical issues aside, it's all about privacy and sending personal information to Apple.
This appears to have been a misinterpretation - or ignorance - of what was really going on with the notarization. In fact, macOS sends opaque information about the developer certificate of the applications you want to open, but not the application name (a developer uses the same certificate in all of their applications) or the device ID. fountain
Apple also responded specifically to this case by updating its note "Open apps safely on your Mac" (the note in Spanish has not yet been updated)
macOS is designed to protect users and their data while respecting their privacy.
Gatekeeper performs online checks to see if an app contains known malware and if the developer certificate has been canceled. We have never combined data from these controls with information about Apple users or their devices. We do not use the data from these controls to find out what each user is opening or using on their device.
The notary checks are just to know that the app does not contain malware and is performed via an encrypted connection prepared to overcome a server failure.
These security checks 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 Developer ID certificate checks and will ensure that all IP addresses are removed from the logs. The security checks 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 will ensure that all collected IP addresses are removed from the 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, the certificate of the HTTPS connection must also be verified using OCSP. This would involve opening another HTTPS connection and so on.
Of course, although OCSP does not require encryption, the responses must be signed by the server.
Problems for Apple
While there is a technical explanation for how this mechanism works in unencrypted HTTP, and Apple's respect for privacy part has been clear enough, there are still two big shadows looming over this issue.
The first is, of course, the image problem, which once again brings shadows of bygone eras when Apple seemed unable to anticipate the demand for its products and the burden it would entail.
That the most precious company in the world has a stumbling block 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 is starting to be called macOS 11, is something truly unheard of.
Of course, Apple isn't alone in miscalculating resources or having disastrous software implementations, but it is the one that attracts the most attention, and a blush is too obvious to turn a blind eye.
According to the article that raised the debate, Apple has left a door open in the end-to-end shutdown of iMessage (Messages). Currently, iOS asks you to enter your Apple ID during setup and automatically enables iCloud backup and iCloud Backup.
iCloud Backup is not end-to-end encrypted - it encrypts the device backup with Apple keys. Any device with iCloud Backup enabled (it is enabled by default) backs up the iMessage history to Apple servers, along with the secret device 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 turned off: Those you're texting with probably haven't turned it off and your conversation is uploaded to Apple (and, via PRISM, available free to the American intelligence community, FBI and other friends, without having to ask for a warrant or have a probable cause).
This certainly deserves some explanation from the company that puts user privacy first. Do not you think?