Following privacy concerns from Mac users after Apple’s Online Certificate Status Protocol (OCSP) server went down, thus causing third-party applications unable to open on Macs, Apple has now responded to the situation, exacerbated by a recent blog post by Jeffrey Paul.
An Apple spokesperson told iPhone in Canada it had updated its support document, ‘Safely open apps on your Mac’, to now further detail its privacy protections.
“Gatekeeper performs online checks to verify if an app contains known malware and whether the developer’s signing certificate is revoked,” explains Apple. “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,” clarified the company.
“Notarization checks if the app contains known malware using an encrypted connection that is resilient to server failures,” says Apple, further emphasizing, “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,” details Apple.
On top of this, Apple says “over the next year we will introduce several changes to our security checks,” specifically:
- a new encrypted protocol for Developer ID certificate revocation checks
- strong protections against server failure
- a new preference for users to opt out of these security protections
Apple also gave some further technical information on the situation to iPhone in Canada. Certificate revocation checks occur to verify that Developer ID certificates used to sign an app have not been revoked by the company. The move is critical for security since a certificate may be pulled if a developer suspects it has been compromised by third parties, or is being used to sign malicious apps.
The industry-standard online certificate status protocol (OCSP) is used by macOS to verify that the Developer ID code signing certificate issued to an app developer has not been revoked. This OCSP request does not include the Apple ID of the user, or reveal a device or app being launched.
Apple says since OCSP is used to check other certificates, including those used to encrypted web connections, these requests happen over unencrypted HTTP, as normal throughout the industry.
HTTP is used to prevent situations where verifying the validity of the certificate that secures the connection to an OCSP server would potentially depend on the result of a request to that same OCSP server, creating a loop that would make it impossible to resolve the request, according to Apple.
Apple says on macOS Catalina and later, by default, all apps running are notarized by the company to note they have been checked by Apple for known malicious software. When an app launches, macOS will check to verify that the app has not been labeled as malicious by Apple since it was first notarized. These checks happen over an encrypted connection—and are resilient to server failures. Which is what happened the other day and users saw their apps hang and take forever to launch.
What caused the OCSP server problem? Apple says it was due to a server-side misconfiguration that specifically interfered with macOS being able to cache OCSP responses for Developer ID. This configuration error, along with an unrelated content delivery network (CDN) misconfiguration, is what caused the slow performance for apps to launch.
Apple explained to iPhone in Canada it has already fixed this performance issue through a server-side update, that will now allow macOS to cache Developer ID OCSP checks for a longer period. macOS users do not need to do anything to benefit from this Apple update.
App notarization checks are used to verify that apps being launched in macOS have not been found to be malicious by Apple, since they were first notarized. Apple says these checks take place over an encrypted connection and are immune to server failures. Notarization checks were not affected by the server-side issue that caused OCSP requests to fail.