LWN: OpenWrt和自签名证书！

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

OpenWrt and self-signed certificates

By Jake Edge
November 18, 2020
DeepL assisted translation
https://lwn.net/Articles/837491/

使用 HTTPS 保护大部分(或所有)网络流量的安全，总的来说是件好事，毕竟许多的个人信息都是通过网络浏览器来传输的。然而，使用 HTTPS 要求网站拥有 TLS 证书，有时这会成为障碍，尽管 Let's Encrypt 已经为许多人解决了这个问题。但有一些系统，它们可能在主人还没来得及采购证书之前就需要进行 HTTPS 保护了。物联网设备和家用路由器就是这样的例子。10 月份的时候，OpenWrt 开发者对这个问题进行了一番探讨。

OpenWrt 是一个家用无线路由器的 Linux 发行版，它提供了一个名为 LuCI 的配置界面，这是一个在此设备上运行的 Web 应用程序。用户可以通过未加密的 HTTP 连接上来，但在某些环境下这样做可能不太合适。在默认设置下，LuCI 不会在路由器的对外界的互联网接口这边监听，而是只可以通过本地局域网的有线访问或者无线访问。不过 OpenWrt 默认情况下也没有启用无线网络。由于路由器的认证凭证（authentication credentials）有可能被恶意攻击者拦截掉，所以很多人会希望 LuCI 只能通过 HTTPS 访问。

OpenWrt 提出了一些建议，用于保护 LuCI 的访问不受攻击，其中就包括要仅允许 HTTPS 访问。但是 LuCI 自带一个自签名（self-signed）的 TLS 证书，所以用户每次访问 LuCI 时都要点击浏览器的安全警告，这样用户体验就不好了。官方也提供了步骤，教用户如何创建一个新的 self-signed 证书，并在设备上和客户端都安装好，这样就不会再看到那个安全警告了。这种做法有很多缺点，尤其是新的证书需要被安装到所有要用来访问 LuCI 的系统上。

理论上来说，只要从 Let's Encrypt 获得证书，就可以解决多数问题了，但这种解决方案也并非那么完美。首先，Lets Encrypt 使用的是自动证书管理环境(ACME，Automated Certificate Management Environment)协议，这要求这个申请证书的系统必须连接到互联网。除此之外，给它分配域名的服务器还需要知道用什么域名来访问这个设备，因此，这个设备首先要有个域名，很显然，"luci.openwrt "或者其他类似的临时名字不能满足这个要求。

在 openwrt-devel 邮件列表上，"abnoeh" 提出了一个有点复杂的方案，可以为 OpenWrt 路由器提供一种获得合格证书的方法。先创建一个 "技术上受限的 subordinate CA "，用它来为 "luci.openwrt.org "的子域名签署证书。不过目前还不完全清楚哪个现有的 CA 愿意签署 subordinate CA keys。Let's Encrypt 和 DigiCert 也许可以。该提案称新的 CA 为 "OpenWrt CA"。

需要获得证书的路由器就要通过加密链路跟 OpenWrt CA 通讯，把自己的 SSH host key 发送过去。CA 再对其进行 Hash 处理，为设备分配 "SSH-hash.luci.openwrt.org" 这个域名。OpenWrt CA 再向路由器发送一个 nonce，i 路由器会创建一个证书签名请求 (CSR, certificate signing request)，对其进行 Hash 处理，然后使用其 SSH host key 对 Hash、 nonce 和时间戳进行签名。CSR 和已签名的消息被发回给 OpenWrt CA，CA 验证信息和签名，然后对证书进行签名，并将其发回给路由器。这时，路由器就有了有效的证书，它可以拦截所有到 SSH-hash.luci.openwrt.org 的连接，将它们 route 给自己，这样使用 HTTPS 访问 LuCI 就不会再引发浏览器警告了，尽管这个主机名可能不太好记。

当然，还有一些问题需要解决，比如尚未连接到互联网的路由器将无法使用这个流程。此外，abnoeh 还指出，这种做法需要运行 OpenWrt CA 服务器，并需要对客户端的请求速率进行合理的限制。还有一个问题是，当 openwrt.org DNS 服务器收到请求要查询 SSH-hash.luci.openwrt.org 的 IP 地址时，这个 DNS 服务器应该怎么回应。

Michael Richardson 想知道，大家是否能找到一个愿意建立 subordinate CA 的 CA。还有，CA/Browser Forum（CABForum）的规则是否会是个障碍。因为，如果 subordinate CA 违反了这些规则的话，浏览器提供商就会将连同整个 CA 一起从浏览器中删除，除非它撤销这个 subordinate CA，这将会引发很多可怕的问题。但 abnoeh 认为这些规则并不阻止我们这种用法。

Abnoeh 确实也在问大家，是不是可以完全弃用 HTTPS，而只用 SSH 来传输对 LuCI 的访问。Alberto Bursi 认为可以考虑在 Android 和 iOS 上提供移动 app，来避开 HTTPS 证书问题，但 Sam Kuper 提醒说，app 不一定能解决问题，尽管看起来似乎很有吸引力。首先，有一些用户没有可以运行这类 app 的设备，并且应用程序也必须以某种合适的方式来解决这个本应用证书来解决的问题。"最终来说，SSL/TLS 在物联网上的应用会是个难题：这两种技术目前还不能很好地相互兼容，这会给用户提出更多要求。"

然而，一些人并不认为需要 CA 颁发的证书，至少在默认情况下并不需要。Fernando Frediani 表示，大多数 OpenWrt 用户都不觉得点击证书警告这件事有什么问题，而且，大多数情况下，LuCI 只会从受信任的网络来访问。但 Richardson 提醒说，这些假设可能会导致意想不到的各种问题。

这样一来，大多数设备就只能从内部网络访问，不应该连到互联网上。于是很多人就不会修改默认密码，而如果恶意软件感染了一台易受攻击的 PC，那么就很容易去攻击 OpenWRT LuCI 接口了。

Bursi 说，OpenWrt 用户哪怕为了要让其在自己的设备上运行起来，已经要克服不少障碍了，应该不太会不更改 root 密码。比如说，默认情况下，OpenWrt 并不会启用 WiFi，这也不是多数用户所期望的设置，他们会想要去改动这个设置：

然后在他们这样做之后，他们还会让设备保持默认吗？也就是配置为 LAN/WAN 路由，没有 wifi，在大多数情况下，这还不如原厂固件。

很多人都认为 abnoeh 的想法是值得尝试的，可以方便那些想要真正证书的用户，但 Bas Mevissen 认为这个建议可能会 "让事情变得比本该有的样子更加困难"。用户应该在一个安全可信的局域网上进行初始安装，并且在将设备连接到互联网之前，或允许他人使用之前先配置好。

所以我认为，如果此前安装的 OpenWRT 中没有可用的证书，那么在第一次启动时通过 HTTP（没有 "S"）进行初始设置是相当可靠。然后，如果有必要的话，用户可以配置好 WAN 这端的设置，并选择是自己上传 Luci 证书（来自本地 PC），还是生成（self-signed）证书，或直接获取（如 Let's Encrypt）证书。之后，就可以切换到 HTTPS，关闭 HTTP。

Mevissen 主要担心的是如何将证书转移到新安装好的 OpenWrt 中。"即使用户/管理员进行配置的时候应该是使用单独的 HTTP 连接，但通过网络来发送那些未加密的东西是不可取的。" Abnoeh 建议使用 U 盘来传输这类机密数据，至少对有 USB 端口的系统来说是该这样做的。

不过 Richardson 想知道那些不太懂技术的用户会怎么做。Mevissen 说，OpenWrt 应该简单地 "以尽可能少的努力（指用户方面所耗费的精力）来获得最好的安全性为目标"。Mevissen 指出，其他路由器通常会为其管理界面配备好 self-signed certificate，因此 OpenWrt 这样做并不是不合群的。为用户提供替换该证书的方法是很重要的，但 abnoeh 的方案似乎太复杂了，不应该采用。

OpenWrt 并不是唯一一个有这个问题的公司。如前所述，物联网设备也有这个问题。其他基于 Web 的管理界面（如 Webmin，Cockpit）也有类似的如何获取初始可靠证书的问题（certificate bootstrap），当然那些设备可能针对的用户会比普通家庭用户更懂技术。不管是好是坏，安全的网络访问从一开始就与 CA 系统绑定在了一起，只有 self-signed 这一个逃生舱可用。无论如何，CA 模式并不适合所有的使用场景，然而，逃生舱却正在慢慢关闭。目前还不完全清楚，那些想要在各种受限环境下（比如没有域名，没有互联网连接）提供安全 HTTP 访问的系统可以做些什么，比起基于 HTTPS 的安全访问来说，能够不要损害安全性，尤其是对于那些技术含量不高的用户来说。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～