更新：以下是我们对UTC下午12:27的看法。为了证实我们的信念，我们把调查集中起来。结果我们错了。虽然这需要努力，但提取私有SSL密钥是可能的。在挑战首次发布后大约9小时，NCSC-FI的软件工程师Fedor Indutny和Ilkka Mattila解决了这个问题。Fedor在一天中发送了250万个请求，Ilkka发送了大约10万个请求。基于这一发现，我们的建议是，每个人都重新颁发并吊销他们的私钥。CloudFlare代表我们管理其SSL密钥的客户加快了这一努力。你可以在这里读更多。广泛使用的开源库OpenSSL周一透露，它有一个主要的bug，现在被称为"心血"。通过向运行未修补版本OpenSSL的易受攻击的服务器发送巧尽心思构建的数据包，攻击者可以获得服务器高达64kB的工作内存。这是一个典型的实现错误的结果，称为缓冲区过读有人猜测，此漏洞可能会暴露服务器证书私钥，使这些网站容易受到模拟攻击。这将是一个灾难性的场景，几乎需要每个服务重新颁发和吊销其SSL证书。请注意，仅仅重新颁发证书是不够的，您还必须撤销它们。不幸的是，证书撤销过程远远不够完美，而且从来没有为大规模撤销而构建。如果每个网站撤销其证书，将对互联网造成巨大的负担和性能惩罚。在CloudFlare规模下，重新颁发和吊销过程可能会破坏CA基础设施。因此，我们花了大量时间与CA合作伙伴进行沟通，以确保我们能够安全、成功地撤销和重新颁发客户的证书。虽然该漏洞似乎有可能使私钥数据面临风险，但迄今为止，还没有关于实际私钥暴露的经核实的报告。在CloudFlare，我们收到了心血漏洞的早期警告，并于12天前修补了我们的系统。我们花了大量时间运行大量的测试，以确定哪些内容可以通过Heartbleed公开，特别是了解私有SSL密钥数据是否存在风险。好消息是：在对我们的软件堆栈进行了大量测试之后，我们无法在易受攻击的服务器上成功地使用Heartbleed来检索任何私钥数据。请注意，这并不等同于说不可能使用Heartbleed来获取私钥。我们还不觉得这样说很舒服。然而，如果可能的话，至少是非常困难的。而且，基于OpenSSL使用的数据结构和我们使用的NGINX的修改版本，我们有理由相信这实际上是不可能的。为了让更多的人关注这个问题，我们创建了一个网站，让全世界都能质疑这个假设：CloudFlare挑战：心血这个网站是由CloudFlare工程师创建的，目的是故意让人心碎。它不是在CloudFlare的网络后面运行的。我们鼓励每个人尝试从本网站获取私钥。如果有人能从这个网站盗取私钥使用心血，我们将在这里发布完整的细节。虽然我们认为私钥数据不太可能被曝光，但我们仍在谨慎行事。我们已经开始重新发布和撤销CloudFlare代表客户管理的密钥。为了确保不会使证书颁发机构资源负担过重，我们正在准备这个过程。我们预计它将在下星期初完成。同时，我们希望我们可以通过我们的众包攻击来获得更多的安全保证。为了让每个人都开始，我们想勾勒出迄今为止我们已经开始的尝试黑客攻击的过程。臭虫心跳信号是一条发送到服务器的消息，服务器可以将其发回。这会让客户机知道服务器仍在连接并监听。heartbleed bug是对心跳消息的响应的实现中的一个错误。这是违规代码p=&s->s3->rrec.数据[0][...]hbtype=*p++；n2s（p，有效载荷）；pl=p；[...]buffer=OPENSSL_malloc（1+2+有效负载+填充）；bp=缓冲器；[...]memcpy（bp，pl，有效载荷）；传入消息存储在一个名为rrec的结构中，其中包含传入的请求数据。代码从第一个字节读取类型（发现它是心跳信号），然后读取下两个字节，这两个字节指示心跳负载的长度。在有效的heartbeat请求中，这个长度与heartbeat请求中发送的有效负载的长度匹配。主要的问题（也是心血的原因）是代码没有检查这个长度是否是heartbeat请求中发送的实际长度，从而允许请求请求比它应该能够检索的更多的数据。然后代码将长度所指示的数据量从传入消息复制到传出消息。如果长度比传入的消息长，软件只会在消息结束后继续复制数据。由于length变量是16位，因此您最多可以从内存请求65535个字节。超过传入消息末尾的数据来自一种无人区，程序不应该访问它，并且可能包含OpenSSL的其他部分留下的数据。

当处理包含比请求有效负载更长长度的请求时，一些未知数据被复制到响应中并发送回客户端。这些额外的数据可以包含敏感信息，如会话cookie和密码，我们将在下一节中介绍。这个错误的修复很简单：检查消息的长度是否与传入请求的长度匹配。如果太长，什么也不回。这正是OpenSSL补丁所做的。马洛克和堆那么什么样的数据可以在请求结束后继续存在呢？技术上的答案是"堆数据"，但更现实的答案是它依赖于平台。在大多数计算机系统中，每个进程都有自己的一组工作内存。通常这被分成两个数据结构：堆栈和堆。在Linux上就是这样，CloudFlare在其服务器上运行的操作系统。具有最大值的内存地址是堆栈数据所在的位置。这包括用于运行程序的本地工作变量和非持久性数据存储。地址空间的最低部分通常包含程序代码，后跟程序所需的静态数据。正上方是堆，所有动态分配的数据都存放在那里。

管理堆上的数据是通过库调用malloc（用于获取内存）和free（用于在不再需要时将其返回）来完成的。当您调用malloc时，程序将在堆区域中选择一些未使用的空间，并将其第一部分的地址返回给您。然后，您的程序就可以在该位置存储数据。调用free时，内存空间被标记为未使用。在大多数情况下，存储在该空间中的数据不会被修改。每个新的分配都需要堆中一些未使用的空间。通常情况下，它被选在有足够空间进行新分配的尽可能低的地址。堆通常向上增长；稍后的分配将获得更高的地址。如果一个数据块被提前分配，它将得到一个低地址，随后的分配将得到更高的地址，除非释放一个大的早期块。这是直接相关的，因为传入消息请求（s->s3->rrec.数据)证书私钥通过malloc在堆上分配。利用漏洞从传入消息的地址读取数据。对于以前分配和释放的请求，它们的数据（包括密码和cookie）可能仍在内存中。如果它们在地址空间中的存储空间比当前请求高出65536个字节，则详细信息可能会泄露给攻击者。请求来来去去，在堆的顶部回收内存。这使得很可能从该攻击中提取以前的请求数据。这对于理解如何使用该漏洞非常重要。以前的请求可能包含密码数据、cookies或其他可利用的数据。由于堆的结构方式不同，私钥是另一回事。好消息是，这意味着私人SSL密钥暴露的可能性大大降低。向上读，不要往下读在NGINX中，当进程启动时会立即加载密钥，这使得密钥在内存空间中的位置非常低。这使得传入的请求不太可能被分配到较低的地址空间。我们做了实验测试。我们修改了NGINX的测试版本，以打印出每个请求在内存中的位置（s->s3->rrec.数据)，只要有心跳。我们将其与内存中存储私钥的位置进行了比较，发现无论发送的请求数量如何，都无法将请求的地址设置为低于私钥的地址。由于该漏洞只读取更高的地址，因此无法用于获取私钥。以下是搜索私钥的视频：如果NGINX被重新加载，它会启动一个新进程并立即加载密钥，将它们放在一个低地址。让一个请求被分配到比早期加载的密钥更低的内存空间是非常不可能的。我们不仅检查了私钥的位置，还编写了一个工具来反复提取额外的数据并将结果写入文件进行分析。我们在这些响应的千兆字节中搜索私钥信息，但没有找到任何私钥信息。我们发现的与证书相关的最有趣的事情是偶尔的公共证书副本（来自previo