☰

Let's Encrypt 如何通过不安全的 http 验证身份？

tag-icon • tag-icon lets-encrypt
Let's Encrypt 如何通过不安全的 http 验证身份？

我刚开始使用 Let's Encrypt。http-01-challenge 非常简单：

效果很好。但是他们如何通过不安全的 http 连接来确保我确实是 example.com 的所有者呢？

我的数据中心（或 ISP）的某些管理员难道不能只请求证书并拦截 Let's Enrypt 发送的 http 请求来检查服务器的身份吗？

答案1

事实上，对于 HTTP-01 质询，没有绝对可靠的保护措施可以抵御中间人攻击。
能够拦截 Let's Encrypt 验证节点和您的服务器之间的流量的人可以通过质询并获得颁发的证书。如果他们能够实施 BGP 欺骗，他们甚至可能不一定处于正常意义上的中间人。
这适用于 HTTP-01 质询，对于未签名的域，也适用于 DNS-01 质询。

值得注意的是，这个问题并非 Lets Encrypt 独有，传统 CA 对 DV 证书进行的验证通常也存在同样的问题；它们通常提供 HTTP、DNS 和电子邮件验证选项，所有这些都容易受到 MITM 攻击。

什么让我们加密有为缓解问题而采取的措施，就是从不同数据中心的多个测试节点运行每个验证，要求所有测试结果一致才能颁发证书。（我怀疑这使得它们比大多数传统 CA 更不容易受到这种滥用的影响。）
这至少缩小了谁可能处于“中间”的范围，因为从不同的测试节点来看，“中间”的大部分将是不同的。

这都是关于 Let's Encrypt（以及一般 CA）的自动域验证的默认行为，但是域所有者被赋予了一些额外的控制权，要求公共 CA 必须检查CAA记录。

为了真正实现控制，域名所有者可以采取以下步骤：

  1. DNSSEC 对区域进行签名，以确保CAA数据不被篡改
    （在 DNS-01 的情况下还可以保护质询本身）
  2. 添加一条或多条CAA记录以限制证书的颁发
    （特别是CAA不仅列出允许颁发证书的 CA，还列出允许颁发该 CA 的哪个帐户的记录）

记录CAA如下：

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12346789"

由于冒名顶替者无法轻易发起挑战，因此问题大大减少。

请特别注意数据accounturi中的参数CAA，这是使策略特定于域所有者在指定 CA 的帐户的原因。仅指定 CA 而不指定帐户的
记录CAA虽然有效，但帮助有限，因为这样的策略仍然允许该 CA 的任何其他客户请求颁发证书。

答案2

使用 http 的理由当获取 HTTP-01 挑战时在规范中：

由于许多 Web 服务器以微妙且非直观的方式为特定的低权限租户用户分配默认的 HTTPS 虚拟主机，因此质询必须通过 HTTP 而不是 HTTPS 完成。

此质询与 ACME 协议消息不同。规范要求使用 https。ACME 还具有正直和重播签名消息的保护。即使流量被捕获，除了未加密的质询之外，还有更多可以破坏流量的方法。当然，这样做存在一定的风险，但更好的域验证程序的替代方案是什么？

监控未经授权证书的更完整方法可能涉及证书透明度。在 CT 日志中搜索或设置您的名称警报。颁发 CA、序列号和日期都应该很熟悉。

相关内容