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

Question

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

• 使网络服务器响应http://example.com
• 要求让我们加密挑战文件
• 在http://example.com/.well-known/acme-challenge 下提供文件
• 接收 example.com 的 TLS 证书

奇迹般有效。但是他们如何使用不安全的 http 连接确保我确实是 example.com 的所有者？

我的数据中心（或我的 ISP）中的某些管理员不能只请求证书并拦截 http 请求，让我们 Enrypt 发送以检查服务器的身份吗？

Answer 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 的域所有者帐户的原因。
一个CAA只有指定CA但不是一个帐户记录，而有效的，将是有限的帮助，这样的政策仍然允许该CA的任何其他客户发出请求，有证书。

Answer 2

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

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

此挑战不同于 ACME 协议消息。该规范要求 https。ACME 还对其签名消息具有完整性和重放保护。即使流量被捕获，破坏它的不仅仅是未加密的挑战。当然，它存在一些风险，但是更好的域验证程序的替代方法是什么？

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