He pointed out that the controversial behavior of macOS Big Sur was 'known for more than two years,' and some even questioned the issue.


macOS Big Sur , released by Apple on November 13, 2020, is suddenly controversial due to privacy concerns, including the fact that it communicates in clear text using the Online Certificate Status Protocol (OCSP) . But Howard Oakley, an engineer who has developed a number of utilities for macOS over the years, said, 'I'm confused that what's been known for more than two years is now making noise.' I point out.

macOS has checked app signatures online for over 2 years – The Eclectic Light Company

Immediately after Apple released macOS Big Sur, a situation occurred that ' slowed down to OS other than Big Sur ' due to a problem related to communication between Mac and server. This incident raised the possibility of suspicious communication by OCSP, so 'I think Big Sur is sending the startup log of the application used by the user to Apple.' Suspicion emerged suddenly.

Does 'macOS Big Sur', which made a major update for the first time in 20 years, really send the application startup log to the outside? --GIGAZINE

Subsequent investigations denied allegations that 'Big Sur is leaking startup logs,' but Big Sur's privacy issues are still under discussion due to OCSP data communications in plaintext. It has become the target of.

Meanwhile, Mr. Oakley pointed out that the behavior in OCSP, which is regarded as a problem this time, 'has been identified for a long time.' He questioned the fact that Big Sur was mentioned as a spear ball. Oakley first saw what was described as 'suspicious communication over OCSP' when he checked the boot log for macOS Mojave (macOS 10.14) released in 2018.

The boot log of macOS 10.14.2 released by Mr. Oakley in 2018 is as follows.

30.343884 SecTrustEvaluateIfNecessary
30.345255 com.apple.securityd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (lsd [355] / 0 # -1 LF = 0)
30.345305 com.apple.securityd cert [2]: AnchorTrusted = (leaf) [force]> 0
30.346576 com.apple.securityd MacOS error: -67030
30.346629 com.apple.securityd MacOS error: -67030
30.361455 SecTrustEvaluateIfNecessary
30.362900 com.apple.securityd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (amfid [124] / 0 # -1 LF = 0)
30.362964 com.apple.securityd cert [2]: AnchorTrusted = (leaf) [force]> 0
30.364183 com.apple.securityd MacOS error: -67030
30.378125 com.apple.securityd MacOS error: -67030
30.378189 com.apple.securityd MacOS error: -67030
30.378271 com.apple.securityd MacOS error: -67030
30.378316 com.apple.securityd MacOS error: -67030
30.378356 com.apple.MobileFileIntegrity Basic requirement validation failed, error: (null)
30.378463 /Applications/SignetTest.app/Contents/MacOS/Signet signature not valid: -67030
30.378478 AMFI: code signing validation failed.
30.380499 SecTrustEvaluateIfNecessary
30.381862 com.apple.securityd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (amfid [124] / 0 # -1 LF = 0)
30.381904 com.apple.securityd cert [2]: AnchorTrusted = (leaf) [force]> 0
30.383124 com.apple.securityd MacOS error: -67030
30.383692 com.apple.MobileFileIntegrity <private>: Broken signature with Team ID fatal.
30.383781 mac_vnode_check_signature: /Applications/SignetTest.app/Contents/MacOS/Signet: code signature validation failed fatally: When validating /Applications/SignetTest.app/Contents/MacOS/Signet:
The code contains a Team ID, but validating its signature failed.
Please check your system log.
30.383800 proc 17245: load code signature error 4 for file 'Signet'
30.403372 com.apple.launchservices RETURNING: {'ApplicationType' = 'Foreground', 'CFBundleExecutablePath' = '/ Applications / SignetTest.app / Contents / MacOS / Signet', 'CFBundleIdentifier' = 'co.eclecticlight.Signet', 'DeathTime' '= now-ish 2018/12/21 09:18:30,' LSBundlePath '=' / Applications / SignetTest.app ',' LSDisplayName '=' SignetTest ',' LSExitStatus '= 9,' pid '= 17245}
30.648151 Saved crash report for Signet [17245] version ??? to Signet_2018-12-21-091830_Howards-iMac-Pro.crash

Oakley said in a log that 'a daemon called com.apple.securityd is repeatedly trying to connect to a certificate revocation list (CRL) through an HTTP connection between OCSP and plaintext, but I'm concerned about this behavior at the time. No one has stated that. '

According to Oakley, previous macOS stored revoked certificate information in a local database for macOS's security feature, Gatekeeper . However, from macOS Catalina, we are switching to online checking via OCSP instead of accessing the database. This online check in OCSP is controversial as a privacy issue, but as mentioned earlier, a similar behavior was discovered in 2018, and no one considered it a problem. ..

Regarding the need for checking using OCSP, Mr. Oakley said, ' There is already a problem that Apple mistakenly approves the Trojan horse application, and macOS quickly validates the signing certificate on the OCSP server. And without proper checking, signatures as a way to distinguish between good and malicious code are almost meaningless. '

On top of that, Oakley said in November 2020 that OCSP's operation in Big Sur is now being criticized, 'Apple's online check on the latest macOS, Those who think it's unnecessary to violate privacy should be well aware of how certificate checking came about and how it's important to macOS security. Despite having enjoyed the benefits of this online check for many years, you'll also be asked to explain why you suddenly decided it was bad and what you could do instead. '

in Software,   Security, Posted by log1l_ks