安裝失敗未包含任何證書

近日，蘋果在釋出會上推出了數款專用晶片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）的用處，並給出瞭解決問題的詳細步驟。

蘋果表示，“從未將這些檢查的資料和蘋果使用者或者他們的裝置捆綁，不會使用這些檢查的資料來了解個人使用者在其裝置上啟動或執行的內容，”並強調“公證檢查應用程式是否包含已知的惡意軟體，使用的是對伺服器故障有彈性的加密連線。這些安全檢查從未包含使用者的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……

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

這些OCSP請求是

未加密傳輸

，也就是說網路上的每個人都能看到，包括你的網路服務提供商，以及所有竊聽者。

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

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

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

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

未加密傳輸

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

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

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

到底是真的假的？

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

補充一點，在關閉Firefox並再次開啟之後，沒有發生任何請求。這是合理的，這表明並沒有在每次啟動時都進行了證書檢查，而是僅在一段時間內未執行證書檢查之後才執行。 這個請求是一個非常簡單的GET，其中包含有效負載作為base64編碼的字串。實際的二進位制資料可以很容易地轉儲到檔案中：

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

顯然，trustdmacOS上的服務不會發送你啟動的應用程式的雜湊值。相反，它只是傳送有關某些證書的資訊。 但這不能解決問題，對嗎？如果每個應用程式都有唯一的證書，那麼仍然有可能建立一個將每個序列號與相應應用程式相關聯的表，因此仍然存在隱私問題。我們來看一下是不是這樣。 開發者認證… 首先，我想確定某個資訊來自哪個證書。我使用Apple的codesign實用程式從Firefox應用程式中提取證書，以查詢匹配的資料。

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

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

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

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

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

作業系統在執行時會向Apple傳送所執行的每個程式的雜湊（唯一識別符號）。

［IP地址］允許具有以下標題的表：日期，時間，計算機，ISP，城市，州，應用程式雜湊

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

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

一般性

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

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

關於公證

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

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

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

關於阻止OCSP

不，macOS不會在每次執行應用程式時向Apple傳送雜湊值。

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

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

既然蘋果已經公佈了應對此次bug的解決方案，網友提出的上述方法似乎也沒有了使用的必要。雖然目前為止，還沒有使用者反饋因此遭受重大實際損失，但暴露出的安全隱私問題，以及網友們對macOS安全技術的討論和關注，再次給人們敲響了警鐘。也許Jeffrey Paul的說法有點誇張，但自詡安全的蘋果在隱私上也並非銅板一塊。正如斯托曼和多克託洛所預言，平日裡我們在安全隱私問題上被溫水煮青蛙，如今這水已經沸騰起來了。