LWN:如何在Fedora中移除SHA-1?

語言: CN / TW / HK

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

Removing SHA-1 for signatures in Fedora

By Jake Edge March 15, 2022 DeepL assisted translation https://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 在這個過程中列出了他提出這個問題的目標:

我想知道,最終,我怎樣才能針對開發人員而不是為使用者來破壞這個機制,以便

  1. 儘早傳達出對它的需求。

  2. 所有相關的地方都能及時確定出來。

  3. 給維護者足夠的時間來解決這個問題或選擇退出。

  4. 而使用者受影響的時間越晚越順利越好。

希望這些都是合理的願望。

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

全文完

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

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

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