使用多域控制器验证确保证书颁发安全

这篇博客帖子是Crypto Week 2019（2019加密周）中的一部分。

公众对互联网的信任是以公钥基础设施（PKI）为基础的。PKI通过签发数字证书，授予服务器安全服务网站的能力，为加密和真实的通信提供了基础。

证书通过使用其中的公钥来验证服务器身份，从而实现HTTPS加密。HTTPS对于传输敏感数据的网站尤为重要，例如传输银行凭据或私人消息的网站。值得庆幸的是，现代浏览器（例如谷歌浏览器）会通过“不安全”字样来标记未使用HTTPS保护的网站，从而令用户在访问网站中更具安全意识。

这篇博文介绍了Cloudflare向CA（证书颁发机构）提供的一种新的免费工具，以便CA能够进一步确保证书颁发安全。但在深入讨论之前，我们先来讨论一下证书的来源。

证书颁发机构（CA）是负责颁发证书的机构。

当CA为任意给定域颁发证书时，它们使用域控制身份验证（DCV）来确认为该域请求证书的实体是否是该域的合法所有者。有了DCV，域的所有者需要：

1. 创建一个域的DNS资源记录；

2. 将文档上传到位于该域的web服务器；或者

3. 证明域名管理电子邮件帐户的所有权。

DCV进程可防止攻击者获取不属于请求者的域的私钥和证书对。

防止攻击者获取这对密钥是至关重要的：如果错误颁发的证书和私钥对落入攻击者手中，他们可能会将自身伪装成受害者的域，并提供敏感的HTTPS流量。这违反了我们对互联网的现有信任，并于大规模的潜在范围内损害了私人数据。

例如，伪装成gmail.com来欺骗CA为其错误地颁发证书的攻击者可以假装自己是谷歌，然后执行TLS握手，并窃取cookie和登录信息，以访问受害者的Gmail帐户。证书错发的风险显然是严重的。

为了防止类似的攻击，CA只在执行DCV之后颁发证书。验证域所有权的一种方法是通过HTTP验证，这一验证通过将一个文本文件上传到web服务器上他们想要保护的特定HTTP端点来完成。另一个DCV方法是使用电子邮件验证来完成的，其中会有一个带有验证代码链接的电子邮件被发送给域的管理联系人。

假设Alice购买了域名aliceswonderland.com，并希望获得该域名的专用证书。Alice选择使用Let’s Encrypt作为其证书颁发机构。首先，Alice必须生成自己的私钥并创建证书签名请求(CSR)。她将CSR发送给Let’s Encrypt，但是直到CA确认Alice拥有aliceswonderland.com前，它都不会为Alice的CSR和私钥颁发证书。然后，Alice可以选择通过HTTP验证来证明她拥有此域名。

当Let’s Encrypt通过HTTP执行DCV时，它们会要求Alice将随机命名的文件放在/.well-known/acme-challenge path for her website中。CA必须通过向http://aliceswonderland.com/.well-known/acme-challenge/<random_filename>发送HTTP GET请求来检索文本文件。在此端点上必须传回一个期望值，DCV才能成功。

为完成HTTP验证，Alice会上传一个文件到http://aliceswonderland.com/.well-known/acme-challenge/YnV0dHNz

其中的主体内容如下：

curl http://aliceswonderland.com/.well-known/acme-challenge/YnV0dHNz

GET /.well-known/acme-challenge/YnV0dHNz
Host: aliceswonderland.com

HTTP/1.1 200 OK
Content-Type: application/octet-stream

YnV0dHNz.TEST_CLIENT_KEY

CA指示它们使用Base64令牌YnV0dHNz。TEST_CLIENT_KEY字段被包含在一个只有证书请求者和CA知道的帐户链接密钥中。CA使用此字段组合来验证证书请求者是否真正拥有该域名。之后，Alice就可以拿到她网站的证书了！

用户验证域所有权的另一种方法是将包含来自CA的验证字符串或令牌的DNS TXT记录添加到域的资源记录中。例如，以下是一个企业向Google验证自己的域名：

$ dig TXT aliceswonderland.com
aliceswonderland.com.	 28 IN TXT "google-site-verification=COanvvo4CIfihirYW6C0jGMUt2zogbE_lC6YBsfvV-U"

在这里，Alice选择创建一个带有特定令牌值的TXT DNS资源记录。谷歌CA可以验证这个令牌的存在，从而验证Alice实际上拥有该网站。

证书的颁发是服务器与客户端安全通信所必须的。这就是为什么确保证书颁发流程的安全如此重要。不幸的是，情况并非总是如此。

普林斯顿大学的研究人员最近发现，普通的DCV方法很容易受到网络层攻击者的攻击。如果说边界网关协议（BGP）是互联网的“邮政服务”，负责通过最有效的路由传递数据，那么自治系统（AS）就是代表由单个组织运行的互联网网络的各个分邮局。有时，网络层的攻击者会在BGP上发布虚假路由，以窃取流量，特别是当流量包含一些重要内容（比如域证书）时。

使用BGP欺骗证书颁发机构凸显了攻击者可以在DCV过程中精心策划的五种攻击类型，以便他们获得非自身所拥有的域名证书。在实施了这些攻击之后，作者（按道理）可以从排名前五的CA（Let 's Encrypt、GoDaddy、Comodo、赛门铁克和GlobalSign）获得非他们所拥有的域名的证书。但是他们是怎么做到的呢？

使用BGP劫持攻击DCV进程有两种主要方法：

1. 子前缀攻击

2. 同等特定前缀攻击

当攻击者为受害者的域发送一个证书签名请求给CA时，这些攻击会创建一个漏洞。当CA使用HTTP GET请求（如前文所述）来验证网络资源时，攻击者紧接着就会使用边界网关协议（BGP）攻击来劫持受害者的域，CA的请求就会被转发给攻击者而非域所有者。为了理解这些攻击是如何进行的，我们需要先做一些数学计算。

互联网上的每个设备都使用IP（互联网协议）地址作为数字标识符。IPv6地址包含128位，并使用斜杠表示法来指示前缀的大小。因此，在网络地址2001:DB8:1000::/48中，“/48”表示的是该网络包含的位数。这意味着还剩下80位数字包含着主机地址，总共有10240个主机地址。前缀号越小，网络中剩余的主机地址就越多。

当BGP声明路由时，路由器总是倾向于选择更具体的路由。所以如果2001:DB8::/32和2001:DB8:1000::/48都被声明，路由器会使用后者，因为后者的前缀更具体。当攻击者使用受害者的域IP地址，让BGP向该特定IP地址声明路由信息时，问题就出现了。让我们设想一下，如果我们的受害者（例如leagueofentropy.com）的IP地址是2001:DB8:1000::1，并且被声明为2001:DB8::/32。如果攻击者声明的前缀2001:DB8:1000::/48，那么他们将可以捕获受害者的流量，并发起_子前缀劫持攻击_。

在IPv4攻击中，比如2018年4月的这次攻击，这个例子中的两个前缀分别是/24和/23声明，更具体的/24前缀是由恶意攻击者声明的。在IPv6中，公告的域名前缀可能是/48和/47。在以上两种情况下，/24和/48都是被允许的全局路由的最小块。在下面的图表中，/47代表德克萨斯州，/48代表更具体的德克萨斯州奥斯汀市。新的（但恶意的）路由覆盖了部分互联网的现有路由。然后攻击者在正常IP地址上运行一个恶意的DNS服务器，DNS记录指向的是一些新的恶意的web服务器，而不是现有的服务器。这吸引（劫持）了前往受害者所有域的流量，同时该域也在传播着恶意信息。此攻击成功的原因是接收路由器总是优先选取更具体的前缀。

在前一次攻击中，攻击者能够通过提供更具体的声明来劫持流量，但是如果受害者的前缀是/48，从而无法进行子前缀攻击怎么办？在这种情况下，攻击者将发起同等特定前缀劫持，其中攻击者声明与受害者相同的前缀。这意味着，AS将根据路径长度等属性在受害者和攻击者的声明路径之间选择。这种攻击只会拦截部分流量。

还有一些更高级的攻击，在本文中有更深入的介绍。这些攻击本质上是相似的，但更为隐蔽。

一旦攻击者成功地获得了一个非他们所有的域的伪造证书，他们就可以执行一个令人信服的攻击，在攻击中他们冒充成受害者的域，并且能够解密和拦截受害者的TLS通信。攻击者解密TLS流量的能力允许他们完全通过中间人攻击（MITM）加密TLS流量，并将目标为受害者域的互联网流量重新路由到攻击者。为了增加攻击的隐蔽性，攻击者还将继续通过受害者的域转发流量，以不被发现的方式进行攻击。

攻击者获得域名控制权的另一种方法是通过使用属于DNS名称服务器的源IP地址欺骗DNS流量。因为任何人都可以修改数据包的出站IP地址，所以对手可以伪造参与解析受害者域的任何DNS名称服务器的IP地址，并在对CA做出响应时模拟名称服务器。

这种攻击比简单地向CA发送伪造DNS响应要复杂得多。因为每个DNS查询都有自己的随机查询标识符和源端口，所以一个伪DNS响应必须匹配DNS查询的标识符才能令人信服。由于这些查询标识符是随机的，使用正确的标识符进行欺骗响应非常困难。

攻击者可以分离用户数据报协议（UDP） DNS包，以便在其中一个包中传递标识DNS响应信息（如随机DNS查询标识符），而在另一个包中传递实际的响应部分。这样一来，攻击者就可以欺骗DNS做出对合法DNS查询才会做出的响应。

假设攻击者想通过强制拆分数据包和欺骗DNS验证来为受害者.com（受害者的域名）获得错误颁发的证书。攻击者只需要给受害者.com的DNS域名服务器发送一个ICMP“需要拆分的”数据包，其大小仅为一个小的最大传输单元（或最大字节）。这将使名称服务器开始对DNS响应进行拆分。当CA向受害者.com的名称服务器发送DNS查询以询问受害者.com的TXT记录时，名称服务器会将响应拆分为以下两个数据包：第一个包含查询ID和源端口，这是攻击者不能冒充的；第二个包含响应部分，可被攻击者利用。在DNS验证过程中，攻击者可以不断地向CA发送假冒的响应，希望在CA从名称服务器接收到真正的响应之前，将他们的假冒响应偷偷传给CA。

这样，DNS响应的回答部分（重要部分！）就可以被伪造，而攻击者可以欺骗CA错误地颁发证书。

乍一看，人们可能认为证书透明（CT）日志可以公开错误颁发的证书，并让CA可以快速撤销它。然而，CT日志可能需要长达24小时的时间才能写入新颁发的证书，不同的浏览器可能遵循着不同的证书撤销流程。我们需要一种解决方案，使CA能够主动地防止这种攻击，而不是在事后进行处理。

我们很高兴地宣布，Cloudflare为CA提供了一个免费的API，可以利用我们的全球网络从世界各地的多个较好的位置执行DCV。这个API支持DCV进程，可以防止BGP劫持和偏离路径的DNS攻击。

考虑到Cloudflare在全球运行175多个（截止至2019年9月已经有193个）数据中心，我们有着从多个有利位置执行DCV的独特地位。每个数据中心都有到DNS名称服务器或HTTP端点的唯一路径，这意味着成功劫持BGP路由只能影响DCV请求的子集，从而使我们能进一步阻碍BGP劫持。由于我们使用RPKI（资源公共密钥基础架构），因此我们实际上也会签名并验证BGP路由。

此DCV检查器还保护CAs免受偏离路径的DNS欺骗攻击。我们在服务中内置的另一个特性是DNS查询源IP随机化，它有助于防止偏离路径的攻击。通过使攻击者无法预测源IP，用伪造的DNS响应的第二个片段欺骗DCV验证代理就变得更具挑战性。

通过比较在多个路径上收集的多个DCV结果，可以看出我们的DCV API使得攻击者在尚未拥有域时，不可能误导CA认为他们拥有域。CA可以使用我们的工具确保它们只向合法的域所有者颁发证书。

我们的多域控制器验证检查器包含两项服务：

1. 负责从特定数据中心执行DCV的DCV代理，以及

2. DCV协调器，用于处理来自CA的多域控制器验证请求，并将它们分派给DCV子代理。

当CA想要确保DCV不被截获时，它可以向我们的API发送请求，指定要执行的DCV的类型及其参数。

然后，DCV协调器会将每个请求转发给不同数据中心中超过20个DCV代理的随机子集。每个DCV代理执行DCV请求并将结果转发给DCV协调器，DCV协调器整合每个代理察看到的内容并将其返回给CA。

这种方法也可以推广到对DNS记录执行多路径查询，比如证书授权（CAA）记录。CAA记录授权CA为域颁发证书，因此多路径查询可以阻止的另一个攻击向量是欺骗它们（CAA）使未经授权的CA可以颁发证书。

在开发多路径检查器时，我们与普林斯顿研究小组进行了交谈，该小组通过BGP劫持攻击引入了证书错误颁发的概念验证（PoC）。Prateek Mittal是BGP paper的_Bamboozling证书颁发机构_的合著者，他写道:

“我们的分析表明，从多个有利位置进行域验证可以显著减轻本地化BGP攻击的影响。我们建议所有证书颁发机构都采用这种方法来增强web安全性。Cloudflare实现这种防御的一个特别吸引人的特性是，Cloudflare可以访问互联网上的大量有利位点，这显著增强了域控制验证的可靠性。”

我们的DCV检查器遵循我们的信念，即互联网上的信任必须是分布式的，并且我们能通过第三方分析（如Cloudflare提供的分析）对此进行审查，以确保其一致性和安全性。此工具被作为一项服务加入了我们已有的证书透明度监控器，欢迎各CA使用此工具改进证书颁发的可靠性。

构建我们的多域控制器验证检查器还让我们可以对多个Cloudflare产品进行内部测试。

作为一个简单的获取器和整合器，DCV协调器是Cloudflare Workers的应用的绝佳选择。我们以这篇文章作为指南，在TypeScript中实现了协调器功能，并创建了一个易于部署和迭代的类型化、可靠的协调器服务。太好了，我们不需要维护我们自己的dcv-orchestrator服务器了！

我们使用Argo Tunnel来让Cloudflare Workers接入DCV代理成为可能。Argo Tunnel可以让我们轻松安全地将DCV暴露在Workers环境中。由于Cloudflare有大约175个（截止至2019年9月已有193个）运行DCV代理的数据中心，我们通过Argo Tunnel公开了许多服务，并且有机会将Argo Tunnel视为具有多种来源的高级用户，在其上加载测试。Argo Tunnel很容易就可以处理好这些新来源的涌入！

如果您和/或您的组织有兴趣尝试我们的DCV检查器，请发送电子邮件至dcv@cloudflare.com告诉我们！我们希望了解有关多路径查询和验证如何增强证书颁发安全性的更多信息。

由于一类新的BGP和IP欺骗攻击可能会破坏PKI（公钥基础设施）基础，因此主张网站所有者在颁发证书时进行多路径验证是非常重要的。我们鼓励所有CA使用多路径验证，无论是Cloudflare还是他们自己的。Let's Encrypt 的技术负责人Jacob Hoffman-Andrews写道：

“BGP劫持是Web PKI仍然需要解决的重大挑战之一，我们认为多路径验证可以成为解决方案的一部分。我们正在测试我们自己的实施结果，我们鼓励其他CA也采用多路径”

希望将来，网站所有者在选择CA时会考虑多路径验证支持。