LWN：如何在Fedora中移除SHA-1？

關注了就能看到更多這麼棒的文章哦～

Removing SHA-1 for signatures in Fedora

By Jake Edge March 15, 2022 DeepL assisted translation http://lwn.net/Articles/887832/ 

破壞性的改動對任何人來說都不是好事，儘管有時候這種改動是無法避免的。比如在加密方面，可能就無法避免需要移除 SHA-1 雜湊函式，這就是一個必須要做的顛覆性改動。SHA-1 有更好的替代品，從加密的角度來看，它在挺早之前就已經被證明是不夠安全了，而且發行版中的大多數軟體元件都可以改用其他雜湊函式。但是，正如最近在 Fedora 開發郵件列表中的討論所展示的，在進行這種轉換時仍有許多障礙需要克服。

How to

3 月 8 日，Alexander Sosedkin 釋出了一封長長的郵件，請求幫助 "為一個破壞性的改動做好規劃"，也就是讓 Fedora 脫離 SHA-1。他說，目前，SHA-1 在 TLS 中已經禁用了，但 SHA-1 還用在很多其他地方，比如軟體包的加密簽名可能還在使用 SHA-1，還有其他一些如 OpenSSL 這樣的庫在某些情況下仍然使用這個陳舊的雜湊演算法。但是，Fedora 不需要成為第一個先行勇者：

好訊息是，RHEL-9 將會做這個先鋒，因此它會先承受很多抨擊。Fedora 則不一定要做這個先行者。壞訊息是，無論如何，Fedora 總有一天要跟進，這就提醒我，應該想想如何實現這樣的改動。

他認為這種改變不可能在一個 Fedora 釋出週期內完成，部分原因是找到並修復 SHA-1 的所有使用位置，就必定會需要破壞一些東西。"唯一現實地把它對 SHA-1 簽名的依賴從無數的邊邊角角中清除出去的方法，就是要破壞這個機制。讓建立和驗證工作在預設配置下直接失敗掉"。但是由於 Fedora 的釋出間隔非常短（兩個版本之間有六個月左右的間隔），即使這樣做也不會給開發人員足夠的時間來修復這些問題，甚至可能有些問題都來不及被發現：

維護者需要時間來收到 bug、研究它們、思考、分析、調整和測試——這還只是在它能按預期的情況來失敗的情況下才行！"。不幸的是，這不僅僅是因為錯誤的方式是各種各樣的，而且還有可能 PC 指標以前從未走到過這段程式碼。一些維護者甚至會發現，選擇不同的雜湊函式會導致他們的程式碼無法互動操作了，甚至他們實現的協議在規範中可能寫死了要用 SHA-1。或者說，一切都準備好了，但現實世界裡完成全部部署還需要十年。或者還有可能，磁碟上的格式很難改變和遷移。

他提出了幾種可能的方法，但不認為簡單地宣佈這個改動就足以完成所有需要進行的改動，他把它比作《銀河系的搭便車指南》中的繞行公告（bypass announcements）。在 Fedora 37 Rawhide 中破壞 SHA-1 簽名的建立和使用，在 release 釋出時撤銷這個變動，然後在 Fedora 38 中再次這樣做（但是不會再撤銷了），這可能是一種可行方法。另一種方法就是在 Rawhide 中直接破壞這個機制，讓它保持這種狀態，但在第一次 release 時撤銷這個改動避免影響使用者。"但這些做法都是相當……粗糙暴力的吧？" 他更希望找到一個更順暢的過程，最好是以前使用過的。

Breaking things

Zbigniew Jędrzejewski-Szmek 不贊成為了找出所有問題領域而直接破壞這個機制。"我們應該讓較新的雜湊值成為系統預設值，我們可以讓工具在不應該使用 sha1 的地方列印一個 warning，但請不要故意破壞它們。" 他還指出，SHA-1 在非加密環境中的使用是完全合理的。除此之外，現有的使用了 SHA-1 的簽名也 "基本上永遠" 需要可以完成驗證，而且使用 SHA-1 的簽名也會被繼續提供出去，畢竟 Fedora 不能規定其他人的簽名政策，所以很有必要能永遠保持檢查這些簽名的功能。這種情況類似於自簽名的 TLS 證書，如果完全禁止它的話，"只會導致使用者轉移到其他的工具"。

Simo Sorce 說，這項工作的重點只是阻止使用 SHA-1 的加密簽名；這意味著 "證書、TLS session 設定、DNSSEC（儘管那裡有很多簽名仍然基於 SHA-1……）、VPN 會話建立、PGP 等……" 雖然他承認驗證 SHA-1 簽名仍然需要被 Fedora 支援，但他認為預設情況下應該是要阻止這個配置。對舊有內容的簽名驗證應該限制在本地資料上，而不要對網路上來的內容使用：

這隻有對像 email 這樣的東西是合理的，在 email 場景裡你可能有一個合理的期望，也就是存檔過的資訊在事後是沒有被篡改過的。對於任何 "online" 通訊來說，不應該繼續允許用 SHA-1 驗證簽名。

Neal Gompa 擔心 "破壞 "SHA-1 驗證可能也會 "破壞 Fedora 的 自己的 GPG 金鑰以及那些第三方首選軟體庫的 GPG 金鑰"。他在給 CentOS 做類似的改動時就遇到了這樣的問題，但 Demi Marie Obenour 說，至少在 Fedora 25 之前的所有官方 RPM 軟體包都有 SHA-256 簽名。Gompa 列出了幾個可能受到影響的第三方軟體庫，RPM Fusion、谷歌、Copr 和微軟。事實證明，Fedora 的 Copr 軟體庫受到了 Gompa 提到的 CentOS 9 改動的影響，Gary Buhrmaster 對此有更全面的報道。有一個 bug 記錄了 Copr 未來使用 SHA-256 簽名的切換相關的工作。

Sosedkin 不同意 Jędrzejewski-Szmek 的想法，也就是不認為 warning 就足夠了；"加密庫無法做任何有意義的記錄，即使他們做了，也會被完全忽視掉，直到我們出現一些東西被破壞的情況。" 他對是否有其他方法來進行這種改動持懷疑態度，儘管向後相容很重要："是的，你仍然可以讓現代的 Fedora 完成 RC4 或 DES，只需要改一點點配置就行。不過，我們仍然必須逐步取消這些預設支援的東西，這是無法避免且必須要做的事情。"

他所指的配置是改變/etc/crypto-policies/config 中的設定，然後執行 update-crypto-policies，這是為 Fedora 21 新增的功能中所介紹的步驟。有三種預定義的設定可用。LEGACY, DEFAULT, 和 FUTURE。這些設定將把各種庫重新配置為不同級別的加密強度。自從增加了這個 policy 選項之後，還增加了對更多庫的支援，policy 本身也為 Fedora 28 和 Fedora 33 進行了更新。

RHEL 9

Daniel P. Berrangé 詢問我們從正在開發中的 RHEL 9 中學到了些什麼，有哪些可以幫助引領 Fedora 的發展方向的。他詢問了受到切換所影響的 RHEL 9 軟體包的數量和百分比，以便更好地瞭解對 Fedora 的影響。"假設 RHEL-9 已經處理了這些問題，Fedora 應該會繼承這些 fix，這給我們在 Fedora 中最常用/最重要的那些軟體包打下了良好的基礎"。他建議，也許只有 "剩下的幾個重要軟體包"需要評估和處理了，而其他的直接讓它出錯應該就行，畢竟可以回退到 LEGACY。

Sosedkin 似乎對這種做法持懷疑態度。他指出，RHEL 9 還沒有廣泛使用，所以其中有多少軟體包被破壞了，這個數量還不清楚。此外，RHEL 所擁有的軟體包大約是 Fedora 的 10%，所以 "把 90% 稱為'不太重要'的軟體包留給'事後修復'會是一場災難"。他重申，他不認為一個週期的時間足以處理這些問題。

雖然 90%的 Fedora 軟體包不會作為 RHEL 9 的一部分來進行測試，但是 Berrangé說，這並不意味著它們可能會受到這一改動的影響。"只有一個相對較小的子集會做加密有關的事情，而其中大部分只是 HTTPS，並完全外包給一個加密庫。" 他認為這些軟體包中可能只有少數會使用 SHA-1 的加密簽名，甚至更少的數量 "會被認為重要到足以阻礙這個改動"。

Alexander Bokovoy 指出了將會遇到的各種問題的一個明確例子。Kerberos 網路認證協議（network-authentication protocol）要求使用 SHA-1 "一方面是由於互操作性的要求，另一方面也是由於要符合 RFC"。他指出 3 月 4 日的 bugzilla 條目報告了這個問題；RHEL 9 的 "fix" 將是覆蓋 Kerberos 的 OpenSSL 中對 SHA-1 的任何限制，而其他可能的做法 "將在 upstream 討論"。當然，Fedora 也會採用這個 fix 方法，但這確實表明這類問題會意外出現。

Warnings

Berrangé還提出了在 stderr 或系統日誌中使用 "一個很嚇人的警告資訊 " 的想法。這可以在一個釋出週期內開啟，看看有哪些錯誤被報告出來。Sosedkin 說，記錄到 log 檔案裡的 warning 資訊基本上不會給出有效 bug，而 stderr 報告會直接導致關於"'$CRYPTOLIB 沒有資格搞亂我的 stderr/stdout'的 bug 報告，我們可能會不得不來撤銷改動從而關閉這些 bug"。

Fedora 專案負責人 Matthew Miller 同意這個想法，儘管它 "比我說的更冷酷無情"。他建議將問題記錄下來，並有一個專門尋找這些日誌資訊的工具，"我們可以做一些類似於 Test Day 在做的事情，人們可以傳送報告"。雖然 Sosedkin 仍然認為由加密庫來記錄日誌是 "危險的做法"，但這是比只記錄到 stderr 更好的做法，"尤其是如果它伴隨著一個需要經過多個釋出週期來完成的改動的話，那麼這些資訊可能是可以減少影響。"

然而，日誌記錄的問題是，可能無法由 library 來呼叫，這取決於程式的執行環境，Berrangé說：

針對 [程序] 所配置的安全策略（SELinux、seccomp、namespaces 或更常見的容器）很容易就能阻止程序訪問 journald、syslog 或開啟日誌檔案的 capability，導致資訊無法記錄下來。在最壞的情況下，在 seccomp 中，試圖使用被阻止的功能可能就會導致應用程式異常中止。

Sosedkin 擔心應用程式可能會以奇怪的方式來重新開啟 stderr 檔案描述符，導致 "把我們這個嚇人的資訊寫到不知道什麼地方去了"，但 Berrangé說這通常來說相當不可能，正是因為各種庫本來已經在需要時向 stderr 列印 warning 和 error 了。"即使是 glibc 在看到 malloc 出錯時也會列印到 stderr，而 stderr 中的東西最終會出現在任何系統服務的 systemd 日誌中。"

SSH?

舊的 SSH 協議使用了 SHA-1，所以 Richard W.M. Jones 想知道這個改動是否會導致 SSH 的使用問題。"這在以前就已經破壞了，要求我們建議使用者將機器的全域性策略設定為 LEGACY（削弱了系統中一切加密技術的效果）"。他還指出，他有一些 "古老的網路裝置"，需要在 Fedora 上進行 LEGACY 設定才能夠確保連線到。他問，Sosedkin 想做的改動是否會進一步影響 SSH。

Sosedkin 說，SSH 使用 SHA-1 作為基於雜湊的訊息驗證碼（HMAC, hash-based message authentication code），"不依賴它來抗碰撞（collision resistance）"，所以不需要做任何改動。Obenour 同意使用 SHA-1 作為 HMAC 是合理的做法，儘管有一些替代品表現得更好；"對 HMAC-SHA-1 沒有已知的攻擊案例"。

Goals

Sosedkin 在這個過程中列出了他提出這個問題的目標：

到目前為止，似乎還沒有一個明確的計劃可以滿足這些目標。這是一個困難的問題，但似乎有可能隨著時間的推移而反覆出現。加密演算法和協議會隨著時間的推移而改變，通常是因為又發現了它們的弱點；一旦它們在一個發行版和網際網路本身中變得根深蒂固了之後，就很難被移除。找到一種方法來順利刪除 SHA-1 —— 至少是儘可能順利地刪除——將是一件有用的事情，要弄清楚。似乎需要更多的討論才行。

全文完

LWN 文章遵循 CC BY-SA 4.0 許可協議。

歡迎分享、轉載及基於現有協議再創作～

長按下面二維碼關注，關注 LWN 深度文章以及開源社群的各種新近言論～