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

关注了就能看到更多这么棒的文章哦～

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 深度文章以及开源社区的各种新近言论～