整理 | 夕顏
php
出品 | CSDN（ID:CSDNnews）
nginx
近日，蘋果在發佈會上推出了數款專用芯片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 也發生了緩慢、中斷和不正常的現象。api
不久以後，一些Mac用戶還發現，當嘗試用trustd（一個負責與Apple的服務器進行覈對，以確認應用程序是否通過認證的MacOS進程）與ocsp.apple.com聯繫時，發生反覆失敗的狀況。這致使App啓動時發生系統性大規模的速度下降。瀏覽器
有用戶反饋，打開控制檯並進行過濾以查找錯誤的用戶，遇到了許多與Trusted相關的連續錯誤，以下圖所示。
緩存
trustd負責覈實Developer ID證書的狀態，而不是公證。但這不是重點。關鍵是，當Apple的CDN掉線時，Apple的OCSP服務器中止響應，而且當這種狀況發生時，許多聯網的Mac就會中止工做。安全
trustd進程只是爲了在沒有聯網狀況下繼續運行，並不是是爲了處理trustd能夠鏈接Apple的OCSP服務器，但服務器沒有響應的狀況。bash
事故發生時，不少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......
這些現象你們彷佛司空見慣，但問題是：
這些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時捕獲瞭如下請求。
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: sha1Issuer Name Hash: 3381D1EFDB68B085214D2EEFAF8C4A69643C2A6CIssuer Key Hash: 5717EDA2CFDC7C98A110E0FCBE872D2CF2E31754Serial 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: sha256WithRSAEncryptionIssuer: CN=Developer ID Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=USValidityNot Before: May 8 19:08:58 2017 GMTNot After : May 9 19:08:58 2022 GMTSubject: 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: sha256WithRSAEncryptionIssuer: CN=Developer ID Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=USValidityNot Before: May 8 19:08:58 2017 GMTNot After : May 9 19:08:58 2022 GMTSubject: 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的說法有點誇張，但自誇安全的蘋果在隱私上也並不是銅板一塊。正如斯托曼和多克託洛所預言，平日裏咱們在安全隱私問題上被溫水煮青蛙，現在這水已經沸騰起來了。
更多精彩推薦
☞我坦白！我是第五位飛上太空的程序員遊客 ☞程序員如何乘風破浪？從數據庫歷史看技術人發展 | CSDN 高校俱樂部 ☞騰訊迴應發佈虛假廣告被罰20萬；蘋果客服迴應iPhone 12屏幕發綠；Chrome 87 正式版發佈|極客頭條 ☞贈書 | 圖像分類問題建模方案探索實踐
☞大神們都是如何在時間序列中進行特徵提取的？看完就懂了！ ☞Value DeFi遭黑客攻擊始末，閃電貸此次又帶走了700萬美圓
點分享點點贊點在看