筆記譯者：為了方便讀者，日期為莫斯科時間
我們最近錯過了用於簽署附加元件的憑證之一的到期時間。 這導致用戶無法使用附加元件。 現在問題已經基本解決，我想分享一下所發生的事情和所做的工作的細節。
背景：補充和簽名
安裝的附加元件必須有 電子簽名，它可以保護使用者免受惡意加載項的侵害，並且需要 Mozilla 員工對加載項進行最少的審查。 我們在 2015 年引入了此要求，因為我們遇到了 嚴重問題 帶有惡意插件。
工作原理：每個 Firefox 副本都包含一個「根憑證」。 這個「根」的密鑰儲存在 硬體安全模組 (HSM)無需網路存取。 每隔幾年，就會使用此密鑰簽署一個新的“中間證書”，該密鑰在簽署附加元件時使用。 當開發人員提交附加元件時，我們會建立一個臨時「最終憑證」並使用中間憑證對其進行簽署。 然後使用最終憑證對附加元件本身進行簽署。 示意性地 看起來像這樣.
請注意，每個證書都有一個「主題」（證書的頒發者）和「頒發者」（證書的頒發者）。 對於根證書，“subject”=“issuer”，但對於其他證書，證書的頒發者是其簽署的父證書的主題。
重要的一點：每個附加元件都由唯一的最終憑證簽名，但這些最終憑證幾乎總是由相同的中間憑證簽署。
作者註：例外是非常舊的添加內容。 當時使用的是各種中級證書。
這種中間證書帶來了問題：每個證書都有一定的有效期限。 在此期限之前或之後，憑證無效，瀏覽器將不會使用由該憑證簽署的加載項。 不幸的是，中級證書於4月4日凌晨XNUMX點到期。
後果並沒有立即顯現。 Firefox 不會持續檢查已安裝附加元件的簽名，而是大約每 24 小時檢查一次，每個使用者的驗證時間都是單獨的。 結果，有些人立即遇到問題，而有些人則晚得多才遇到問題。 我們在證書過期時首次意識到該問題，並立即開始尋找解決方案。
減少傷害
一旦我們意識到發生了什麼事，我們就盡力防止情況變得更糟。
首先，他們停止接受和簽署新的補充。 為此使用過期的憑證是沒有意義的。 回顧過去，我想說我們本來可以讓一切保持原樣。 我們現在已經恢復接受補品。
其次，他們立即發布了修復程序，阻止每天檢查簽名。 因此，我們保留了那些在過去 XNUMX 小時內瀏覽器還沒有時間檢查附加元件的使用者。 此修復現已撤回，不再需要。
並聯運行
理論上，該問題的解決方案看起來很簡單：建立一個新的有效中間憑證並重新簽署每個附加元件。 不幸的是，這行不通：
- 我們無法一次快速重新簽署 15 個附加元件，該系統不是為這樣的負載而設計的
- 在我們簽署新增內容後，需要將更新的版本交付給使用者。 大多數附加元件都是從 Mozilla 伺服器安裝的，因此 Firefox 將在接下來的 XNUMX 小時內找到更新，但一些開發人員透過第三方管道分發簽章附加元件，因此用戶必須手動更新此類附加元件
相反，我們嘗試開發一種修復程序，無需用戶採取太多操作或無需採取任何操作，即可覆蓋所有用戶。
很快我們就得出了兩個並行使用的主要策略：
- 更新 Firefox 以變更憑證有效期限。 這將使現有的附加元件再次神奇地工作，但需要發布和發布新版本的 Firefox
- 產生一個有效的證書並以某種方式說服 Firefox 接受它而不是已過期的現有證書
我們決定先使用第一個選項，它看起來相當可行。 最終，他們發布了第二個修復程式（新證書），我們稍後會討論。
更換證書
正如我上面提到的，需要：
- 建立新的有效證書
- 在 Firefox 中遠端安裝
為了理解為什麼會這樣，讓我們仔細看看附加元件驗證過程。 此附加元件本身是作為一組文件提供，包括用於簽署的憑證鏈。 因此，如果瀏覽器知道根憑證（在建置時內建在 Firefox 中），則可以驗證該附加元件。 但是，正如我們所知，中間憑證已過期，因此無法驗證該附加元件。
當 Firefox 嘗試驗證附加元件時，它不僅限於使用附加元件本身包含的憑證。 相反，瀏覽器會嘗試建立有效的憑證鏈，從最終憑證開始一直持續到根憑證。 在第一級，我們從最終證書開始，然後找到主體為最終證書（即中間證書）的頒發者的證書。 通常，此中間憑證隨附加元件一起提供，但瀏覽器儲存體中的任何憑證也可以用作此中間憑證。 如果我們可以遠端將新的有效憑證新增至憑證儲存中，Firefox 將嘗試使用它。 安裝新證書前後的情況.
安裝新憑證後，Firefox 在驗證憑證鏈時將有兩個選項：使用舊的無效憑證（不起作用）或新的有效憑證（將起作用）。 重要的是，新憑證包含與舊憑證相同的主題名稱和公鑰，因此它在最終憑證上的簽章將有效。 Firefox 足夠聰明，可以嘗試這兩種選項，直到找到有效的選項，因此插件會再次經過測試。 請注意，這與我們用於驗證 TLS 憑證的邏輯相同。
作者註：熟悉 WebPKI 的讀者會注意到交叉憑證的工作方式完全相同。
此修復的優點在於它不需要您重新簽署現有的附加元件。 一旦瀏覽器收到新證書，所有附加元件將再次運行。 剩下的挑戰是向使用者提供新憑證（自動和遠端），以及讓 Firefox 重新檢查已停用的附加元件。
諾曼第和研究系統
諷刺的是，這個問題是透過一個名為「系統」的特殊附加元件解決的。 為了進行研究，我們開發了一個名為 Normandy 的系統，為使用者提供研究成果。 這些研究在瀏覽器中自動執行，並增強了對 Firefox 內部 API 的存取。 研究可以將新憑證新增到憑證儲存中。
作者註：我們不會新增具有任何特殊權限的憑證； 它由根憑證簽名，因此 Firefox 信任它。 我們只需將其新增至瀏覽器可以使用的憑證池中即可。
因此，解決方案是創建一項研究：
- 安裝我們為使用者建立的新證書
- 強制瀏覽器重新檢查已停用的加載項，以便它們再次工作
“但是等等，”你說，“附加元件不起作用，我如何啟動系統附加元件？” 讓我們用新證書來簽名吧！
把所有這些放在一起......為什麼花了這麼長時間？
因此，計劃是：頒發一個新證書來替換舊證書，創建一個系統附加元件並透過 Normandy 將其安裝給使用者。 正如我所說，問題於 4 月 4 日 00:12 開始，並在當天 44:9 不到 6 小時後，我們向諾曼第發送了修復。 又花了 12 到 XNUMX 個小時才到達所有用戶。 一點也不壞，但 Twitter 上的人們在問我們為什麼不能更快採取行動。
首先，頒發新的中級證書需要時間。 正如我上面提到的，根憑證的金鑰離線儲存在硬體安全模組中。 從安全角度來看，這很好，因為根很少使用，應該受到可靠保護，但當您需要緊急簽署新證書時，這有點不方便。 我們的一位工程師必須前往 HSM 儲存設施。 然後，又多次嘗試頒發正確的證書，但均未成功，每次嘗試都需要花費一兩個小時進行測試。
其次，系統附加元件的開發也花了一些時間。 從概念上講，它非常簡單，但即使是簡單的程式也需要小心。 我們想確保我們不會讓情況變得更糟。 研究在發送給用戶之前需要進行測試。 此外，必須對附加元件進行簽名，但我們的附加元件簽名系統已停用，因此我們必須找到解決方法。
最後，當我們準備好提交研究後，部署就需要時間了。 瀏覽器每 6 小時檢查一次 Normandy 更新。 並非所有電腦都始終處於開啟狀態並連接到互聯網，因此修復程式需要一段時間才能傳播給使用者。
最後步驟
該研究應該可以解決大多數用戶的問題，但並非所有人都可以使用。 有些用戶需要特殊的方法：
- 停用研究或遙測的用戶
- Android 版本（Fennec）的用戶，根本不支援研究
- 在無法啟用遙測的企業中使用 Firefox ESR 自訂版本的用戶
- 坐在 MitM 代理程式後面的用戶，因為我們的附加安裝系統使用金鑰固定，這不適用於此類代理
- 使用不支援研究的舊版 Firefox 的用戶
我們對後一類用戶無能為力——他們仍然應該更新到新版本的 Firefox，因為過時的版本存在嚴重的未修補的漏洞。 我們知道有些人仍然使用舊版本的 Firefox，因為他們想運行舊的附加元件，但許多舊的附加元件已經移植到新版本的瀏覽器上。 對於其他用戶，我們開發了一個補丁來安裝新憑證。 它作為錯誤修復版本發布（譯者註：Firefox 66.0.5），因此人們會透過常規更新管道獲得它 - 很可能已經獲得它。 如果您使用的是 Firefox ESR 的自訂版本，請聯絡您的維修人員。
我們知道這並不理想。 在某些情況下，使用者會遺失附加資料（例如，附加數據 多帳戶容器).
這種副作用是無法避免的，但我們相信在短期內我們已經為大多數使用者選擇了最佳解決方案。 從長遠來看，我們將尋找其他更先進的架構方法。
Уроки
首先，我們的團隊在發現問題後不到 12 小時內就創建並發布了修復程序，做得非常出色。 作為一個參加會議的人，我可以說，在這種困難的情況下，人們非常努力，幾乎沒有浪費時間。
顯然，這一切根本不該發生。 顯然，調整我們的流程以減少此類事件發生的可能性並使補救變得更容易是值得的。
下週我們將發布正式的事後分析和我們打算進行的更改清單。 現在，我將分享我的想法。 首先，一定有更好的方法來監控潛在定時炸彈的狀態。 我們需要確保我們不會發現自己處於其中一個突然起作用的情況。 我們仍在製定細節，但至少有必要考慮到所有這些事情。
其次，我們需要一種機制來快速向用戶提供更新，即使在其他一切都失敗的情況下（尤其是當）。 我們能夠使用「研究」系統真是太好了，但它是一個不完美的工具，並且有一些不必要的副作用。 特別是，我們知道許多用戶打開了自動更新，但不願意參與研究（我承認，我也關閉了它們！）。 同時，我們需要一種向用戶發送更新的方法，但無論內部技術實現如何，用戶都應該能夠訂閱更新（包括修補程式），但選擇退出其他所有內容。 此外，更新通道的響應速度應該比現在更快。 即使在 6 月 XNUMX 日，仍然有用戶沒有利用修復程式或新版本。 這個問題已經解決，但發生的事情表明了它的重要性。
最後，我們將仔細研究該附加元件的安全架構，以確保它提供適當的安全級別，並將破壞任何內容的風險降至最低。
下週我們將查看對所發生事件進行更徹底分析的結果，但同時我很樂意透過電子郵件回答問題： [電子郵件保護]
來源： linux.org.ru