全球數百萬臺 Mac 疑似因 Big Sur 更新險釀計算災難，蘋果官方回應來了！

整理 | 夕顏

出品 | CSDN（ID:CSDNnews）

近日，蘋果在發布會上推出了數款專用芯片M1支持的Mac新品，包括Mac book、MacBook Pro和Mac mini系列，隨之一起重磅發布的，還有macOS 11.0，也就是大家熟知的Big Sur正式版，

然而，當用戶上手體驗時，卻發現Big Sur下載程序緩慢，而且出現突然中斷的情況，必須重啟設備，與此同時，蘋果的開發者網站也發生問題，導致部分第三方應用程式無法打開，

這些問題似乎出現在新版Big Sur推出之際，并影響了其他版本的macOS用戶，比如Catalina和Mojave，其他的Apple服務，包括Apple Pay, Messages甚至Apple TV 也發生了緩慢、中斷和不正常的現象，

不久之后，一些Mac用戶還發現，當嘗試用trustd（一個負責與Apple的服務器進行核對，以確認應用程式是否經過認證的MacOS行程）與ocsp.apple.com聯系時，發生反復失敗的情況，這導致App啟動時發生系統性大規模的速度降低，

有用戶反饋，打開控制臺并進行過濾以查找錯誤的用戶，遇到了許多與Trusted相關的連續錯誤，如下圖所示，

trustd負責核實Developer ID證書的狀態，而不是公證，但這不是重點，關鍵是，當Apple的CDN掉線時，Apple的OCSP服務器停止回應，并且當這種情況發生時，許多聯網的Mac就會停止作業，

trustd行程只是為了在沒有聯網情況下繼續運行，并非是為了處理trustd可以連接Apple的OCSP服務器，但服務器沒有回應的情況，

事故發生時，很多Mac用戶完全不知道為什么他們的應用啟動不了，還擔心是不是作業系統或者硬體出了問題，

蘋果回應故障原因，更新支持檔案

昨日，蘋果對這場“意外”進行了官方回應，稱導致OCSP服務器出現問題的原因，是由于服務器端的錯誤配置，特別是干擾了macOS能夠為開發者ID快取OCSP回應，這個配置錯誤，以及一個不相關的內容傳輸網路(CDN)的錯誤配置，是導致應用程式啟動性能緩慢的原因，蘋果表示，目前已通過服務器端更新修復了這一性能問題，現在將允許macOS在更長的時間內快取開發者ID OCSP檢查，macOS用戶不需要任何操作，

在支持檔案更新中，蘋果解釋了“門禁（Gatekeeper）的用處，并給出了解決問題的詳細步驟，具體可參考https://support.apple.com/en-us/HT202491

蘋果表示，“從未將這些檢查的資料和蘋果用戶或者他們的設備捆綁，不會使用這些檢查的資料來了解個人用戶在其設備上啟動或運行的內容，”并強調“公證檢查應用程式是否包含已知的惡意軟體，使用的是對服務器故障有彈性的加密連接，這些安全檢查從未包含用戶的Apple ID或其設備的身份，為了進一步保護隱私，我們已經停止記錄與開發者ID證書檢查相關的IP地址，我們將確保從日志中洗掉任何收集到的IP地址”，

此外蘋果還承諾在接下來的一年時間里，將會對安全檢查進行一些調整，具體包括：

● 一個針對開發者 ID 的全新加密協議，用于驗證該 ID 是否被撤銷；

● 強大的保護措施，防止服務器故障；

● 用戶可以選擇不接受這些安全保護的新偏好，

至此，這場波及全球數百萬臺Mac設備的事故引發的爭議似乎要告一段落了，但在這個程序中，一些網友針對macOS出現問題的解決辦法，以及關于macOS安全隱私問題的爭議，也值得探討一下，

這究竟是怎么回事呢？

用第三方防火墻，但被指存在安全隱患

話說是在Big Sur正式版發布之后一些Mac設備打開第三方App出現卡死現象后不久，就有萬能的網友在就找到了應對這個bug的方法，那就是讓用戶使用第三方防火墻軟體，比如LuLu、Little Snitch等，這些應用可以連接到ocsp.apple.com，繞過認證環節，直接下載App，

提出這個方法的是Jeff Johnson，這是一位擁有數十年MacOS和iOS開發經驗的開發者，因為針對這件事頻頻在Twitter發聲，Jeff Johnson一時成了網路紅人，

然而，雖然Jeff Johnson提出的方法能奏效，但這種方法其實存在著巨大的安全隱患，一名黑客&安全研究員Jeffrey Paul的文章Your Computer Isn't Yours 尤其引起了廣泛的關注，在文中，他指出macOS一些現存機制已經嚴重地影響了用戶的隱私安全，

什么是OCSP？

為什么用第三方防火墻會引發安全隱患？首先，我們需要搞清楚什么是OCSP，

OCSP（Online Certificate Status Protocol）意為在線證書狀態協議，顧名思義，它用于驗證證書的有效性，而不必下載和掃描大型證書吊銷串列，啟動Mac應用程式時，macOS使用OCSP來確保在應用程式在啟動之前未被吊銷開發人員證書，

自2012年以來，macOS（當時稱為Mac OS X）要求從Web下載的所有應用程式（Mac App Store外部）都必須使用由Apple頒發給開發人員的有效Developer ID證書進行簽名，蘋果認為，Developer ID的目的是防止惡意軟體傳播，開發人員已分發惡意軟體一旦被發現，Apple就撤銷該開發人員的代碼簽名證書，macOS也將阻止啟動任何使用該證書簽名的軟體，從而保護Mac用戶，

但這個證書有一點不好，如果Developer ID OCSP的互聯網連接出現問題，可能會阻止Mac應用程式啟動，在上周四Big Sur發生故障的的幾個小時中，全世界數百萬臺Mac在啟動安裝的應用程式時都遇到了極其緩慢的情況，可以稱得上是一次短暫的重大計算災難，

繞過防火墻，留下安全隱患

可以看到，蘋果Developer ID OCSP的初衷就是為了保證應用程式的安全性，在之前的macOS版本中，會用網路內核拓展構建防火墻，但是新版系統中，蘋果棄用了這些拓展，導致很多App可以繞過防火墻，直接下載，如果使用第三方軟體繞過防火墻，macOS無法觸動Apple的OCSP回應程式，就將跳過檢查，直接啟動該應用程式，這本質上是一種出故障時自動打開的機制，意味著下載的App安全性根本無從保證，

這個機制要求macOS在啟動應用程式之前與Apple聯系，這時與ocsp.apple.com失聯，蘋果的回應程式并沒有失效，用戶雖然可以觸動回應程式，但程序變得非常緩慢，

macOS運行時向Apple發送每個程式的哈希值？

拔出蘿卜帶出泥，在研究Developer ID OCSP的程序中，安全研究員 Jeffrey Paul發現了一個漏洞，會威脅到用戶的隱私安全，

他在文章中聲稱，在當前版本的macOS中，作業系統在運行時，會向Apple發送用戶運行的每個程式的哈希值（唯一識別符號）！很多人沒有意識到這一點的嚴重性，只要用Mac聯網，任何連接服務器的第三方都可以看到你的IP、輸入時間，并進行粗略的城市及和ISP級地理定位，也可以為通用程式計算這些哈希值，包括App Store中的所有內容、Creative Cloud、Tor瀏覽器、破解或逆向工程工具等，這意味著，蘋果可以知道你何時在家，何時在作業，甚至在朋友家的WiFi上打開了Premiere......

這些現象大家似乎司空見慣，但問題是：

1. 這些OCSP請求是未加密傳輸，也就是說網路上的每個人都能看到，包括你的網路服務提供商，以及所有竊聽者，

2. 這些請求將被轉到另一家公司Akamai經營的第三方CDN，

3. 棱鏡計劃讓美國聯邦警察和軍方隨時隨地不受限制地訪問這些資料，而無需發出任何指令，

更糟的是，OCSP通常使用HTTP，如果使用HTTPS通過OCSP檢查證書，則還需要使用OCSP檢查HTTPS連接的證書，這意味著打開另一個HTTPS連接，依此類推，

當然，盡管OCSP不要求加密，但確實要求回應由服務器簽名，這仍然不能解決我們最初擔心的問題，即如果在網路上裝上流量分析器，任何人都可以“竊聽”你打開的每個應用程式，以及打開應用程式的時間，

真的假的？

這些要是真的，那真是太可怕了！

問題是，Jeffrey Paul在文章中提到的macOS涉及的安全問題是真實的嗎？對此，有人提出了疑問，比如這位米蘭理工大學的碩士研究生Jacopo Jannone，他在一篇博客中從技術的角度進行了詳細的分析，

這些疑問包括：OCSP是關于檢查證書的，那跟發送運行的應用程式的哈希值有什么關系？macOS每次啟動時是否真的計算每個可執行檔案的哈希值？那超大的檔案呢？這個程序要花費大量時間，可能沒有人注意到嗎？也許哈希僅計算一次（例如，第一次運行該應用程式時），并將其存盤在某個位置，但Jacopo Jannone表示，Jeffrey Paul的說法需要進一步的研究，

為了證明自己的質疑，他貼出了自己求證的程序（以下為譯文）：

捕獲OCSP請求就像設定HTTP代理或啟動Wireshark一樣容易，沒有HTTPS意味著沒有加密，沒有證書固定，沒有任何問題，我在Firefox時捕獲了以下請求，

GET /ocsp-devid01/ME4wTKADAgEAMEUwQzBBMAkGBSsOAwIaBQAEFDOB0e%2FbaLCFIU0u76%2BMSmlkPCpsBBRXF%2B2iz9x8mKEQ4Py%2Bhy0s8uMXVAIIBseUIWx6qTA%3D HTTP/1.1Host: ocsp.apple.comAccept: */*User-Agent: com.apple.trustd/2.0Accept-Language: it-itAccept-Encoding: gzip, deflateConnection: keep-alive

補充一點，在關閉Firefox并再次打開之后，沒有發生任何請求，這是合理的，這表明并沒有在每次啟動時都進行了證書檢查，而是僅在一段時間內未執行證書檢查之后才執行，

這個請求是一個非常簡單的GET，其中包含有效負載作為base64編碼的字串，實際的二進制資料可以很容易地轉儲到檔案中：

echo 'ME4wTKADAgEAMEUwQzBBMAkGBSsOAwIaBQAEFDOB0e/baLCFIU0u76+MSmlkPCpsBBRXF+2iz9x8mKEQ4Py+hy0s8uMXVAIIBseUIWx6qTA=' | base64 --decode > output.bin

我們獲得了一個80位元組長的有效負載，看起來根本就不像一個哈希，事實上還真不是，我們可以使用OpenSSL從二進制檔案中提取可讀資訊，

openssl ocsp -text -reqin output.binOCSP Request Data:    Version: 1 (0x0)    Requestor List:        Certificate ID:          Hash Algorithm: sha1          Issuer Name Hash: 3381D1EFDB68B085214D2EEFAF8C4A69643C2A6C          Issuer Key Hash: 5717EDA2CFDC7C98A110E0FCBE872D2CF2E31754          Serial Number: 06C794216C7AA930

顯然，trustdmacOS上的服務不會發送你啟動的應用程式的哈希值，相反，它只是發送有關某些證書的資訊，

但這不能解決問題，對嗎？如果每個應用程式都有唯一的證書，那么仍然有可能創建一個將每個序列號與相應應用程式相關聯的表，因此仍然存在隱私問題，我們來看一下是不是這樣，

開發者認證…

首先，我想確定某個資訊來自哪個證書，我使用Apple的codesign實用程式從Firefox應用程式中提取證書，以查找匹配的資料，

codesign -d --extract-certificates /Applications/Firefox.app

此命令創建了幾個名稱為codesign0，codesign1等的檔案，第一個是葉證書，而其他檔案則屬于根目錄的證書鏈，codesign0應該就是我們要找的東西，我們可以再次用OpenSSL提取有關資訊，

openssl x509 -inform der -in codesign0 -textCertificate:    Data:        Version: 3 (0x2)        Serial Number: 488521955867797808 (0x6c794216c7aa930)    Signature Algorithm: sha256WithRSAEncryption        Issuer: CN=Developer ID Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=US        Validity            Not Before: May  8 19:08:58 2017 GMT            Not After : May  9 19:08:58 2022 GMT        Subject: UID=43AQ936H96, CN=Developer ID Application: Mozilla Corporation (43AQ936H96), OU=43AQ936H96, O=Mozilla Corporation, C=US        ...

檢查一下我們獲得的序列號（0x6c794216c7aa930），并將其與OCSP請求的有效負載進行比較，結果證明，OCSP請求實際上發出了有關應用程式開發者證書的資訊，

一般性

“所以呢？” 你可能會問，嗯，并非每個應用程式都有唯一的開發人員證書，耳聽為虛，我們可以通過檢查來自Mozilla的其他應用程式的證書來快速驗證這一點，比如Thunderbird，

codesign -d --extract-certificates /Applications/Thunderbird.appopenssl x509 -inform der -in codesign0 -textCertificate:    Data:        Version: 3 (0x2)        Serial Number: 488521955867797808 (0x6c794216c7aa930)    Signature Algorithm: sha256WithRSAEncryption        Issuer: CN=Developer ID Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=US        Validity            Not Before: May  8 19:08:58 2017 GMT            Not After : May  9 19:08:58 2022 GMT        Subject: UID=43AQ936H96, CN=Developer ID Application: Mozilla Corporation (43AQ936H96), OU=43AQ936H96, O=Mozilla Corporation, C=US        ...

這與用于Firefox的證書完全相同（當然是！），因此，Jeffrey Paul的分析不夠準確，至少對于涉及這些部分的問題，

作業系統在運行時會向Apple發送所運行的每個程式的哈希（唯一識別符號），

[IP地址]允許具有以下標題的表：日期，時間，計算機，ISP，城市，州，應用程式哈希

[這意味著Apple知道]你在哪里打開了哪些應用，以及打開頻率，他們知道你何時在你朋友家的Wi-Fi上打開Premiere，并且知道你何時在前往另一座城市的旅館中打開Tor瀏覽器，

macOS實際上確實發出了有關這些應用程式的開發人員證書的一些不透明資訊，這在隱私角度上是非常重要的區別，

關于公證

有些概念可能是造成這種誤解的根源，實際上，在一種情況下，macOS的確可以向蘋果發送可執行檔案的哈希值，即應用程式首次啟動時，Gatekeeper會檢查Apple的服務器上是否有公證單，

這其實與OCSP無關，只在特定的情況下才會發生，而且檢查是通過位于api.apple-cloudkit.com的安全（HTTPS）端點，在此程序中，用戶會看到一個帶有進度欄的彈出視窗，

關于阻止OCSP

正如你可能已經在Apple的OCSP回應器中斷期間了解到的那樣，你可以通過幾種方式阻止OCSP請求，其中最受歡迎的是Little Snitch ，并編輯/etc/hosts檔案，就個人而言，我不建議這樣做，因為它會使重要的安全功能無法正常作業，

現在，了解了這些事實，如果你認為此功能對你的隱私造成的威脅大于在系統上運行潛在的未被檢測到的惡意軟體，可以繼續用這種方法，否則，不要冒險，

如果你用的是macOS Big Sur，則阻止OCSP可能不那么容易，請記住，普通用戶通常無法完全理解和評估禁用這種復雜而微妙的安全功能，會對自己的計算機產生怎樣的影響，

觀點總結

• 不，macOS不會在每次運行應用程式時向Apple發送哈希值，

• 注意，macOS可能會傳送有關你運行的應用程式的開發者證書的一些不透明資訊，此資訊以明文形式發送到你的網路上，

• 你也許不應該用Little Snitch，或在你的主機檔案中阻止ocsp.apple.com，

結尾

既然蘋果已經公布了應對此次bug的解決方案，網友提出的上述方法似乎也沒有了使用的必要，雖然目前為止，還沒有用戶反饋因此遭受重大實際損失，但暴露出的安全隱私問題，以及網友們對macOS安全技術的討論和關注，再次給人們敲響了警鐘，

也許Jeffrey Paul的說法有點夸張，但自詡安全的蘋果在隱私上也并非銅板一塊，正如斯托曼和多克托洛所預言，平日里我們在安全隱私問題上被溫水煮青蛙，如今這水已經沸騰起來了，

更多精彩推薦

?JavaScript 穩居第一、C# 連續下跌，調查 17000 名程式員后有了這些新發現！
?龍飛船再次發射成功！馬斯克無緣現場，因疑似感染新冠……?從互聯網大廠裸辭 500 天后，我發生哪些變化？
?64歲Python之父退休失敗，正式加入微軟搞開源

?如何破解“中國開源拿來主義”？包云崗的幾點分析
?2020年，區塊鏈和加密領域的女性數量激增

點分享點點贊點在看