11天前，心血漏洞被公开宣布。上周五，我们发布了CloudFlare Challenge:Heartbleed，同时启动了撤销和重新颁发CloudFlare为客户管理的所有SSL证书的过程。这个过程现在已经完成。我们已经撤销并重新颁发了我们管理的每一个证书以及我们使用的所有证书。这种大规模撤销在ISC的CRL活动图上显示得非常明显。

鼓励使用自定义证书的客户重新密钥、上载新证书并吊销以前的自定义证书。背景我们上周一宣布，我们已经修补了OpenSSL中的一个错误，我们的客户是安全的。我们当时并不知道CloudFlare是在公开宣布之前向少数人披露该缺陷的公司之一。事实上，我们甚至不知道臭虫的名字。当时，我们只是通过重新编译OpenSSL_NO_HEARTBEATS选项从OpenSSL中完全删除了TLS心跳功能。在了解了这个漏洞的全部情况并知道它已经在互联网上传播了两年之后，我们开始了一项调查，看看我们的私钥和客户的私钥是否存在风险。我们开始调查的时候试图从心血中得到什么样的信息。我们在一台本地机器上设置了一个测试服务器，并对其进行了大量的心跳攻击，从而节省了它返回的内存块。我们扫描了内存以寻找私钥的副本，经过广泛的扫描，我们找不到它的踪迹。尽管如此，我们并不完全相信这是不可能的，所以我们决定通过设立CloudFlare Heartbleed Challenge来众包问题。挑战开始9小时后，推特（Twitter）上披露了这把钥匙的初审结果。在五天的挑战中，我们看到了7500多万次针对我们服务器的心血攻击和8000次提交。挑战的胜利者使用两种不同的技术来获得私钥。私钥是怎么泄露的通过查看代码，我们知道在私钥操作的计算过程中，密钥的某些片段被复制和操纵。在代码进入bn_div.c之后，该代码最终生成除数的副本（在模数运算中）：/*首先，我们将数字标准化*/norm_shift=BN_位2-（（BN_num_位（除数））%BN_位2；如果（！（BN_lshift（sdiv，除数，norm_shift）））转到错误；存储在sdiv中的值最终保留在内存中，直到有东西覆盖它。除数是RSA所需的两个素数p和q之一。下面是更多信息。但是这里有一个图表显示了OpenSSL内部的内存。图中显示了26个HTTPS请求（大小不同）被发送后的内存状态。黑色内存未使用，绿色内存正在使用中，红色内存包含私钥，黄色内存包含私钥的剩余部分。

残余物使Heartbleed泄漏私钥。OpenSSL将大量的绿色（在用）内存用作缓冲区（处理请求和响应的内存）。如果黄色钥匙残留物附近的一些绿色内存用于心出血请求，黄色内存可能会复制到心出血响应中，密钥可能会泄漏。以下是记忆中的情景：（gdb）x/128xb 0xbd15600xbd1560:0xe0 0x09 0xbd 0x00 0x00 0x00 0x00 0x000xbd1568:0xf0 0x34 0xbb 0x00 0x00 0x00 0x00 0x000xbd1570:0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x000xbd1578:0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x000xbd1580:0x0f 0x47 0x67 0xe0 0x03 0x11 0x56 0x7d0xbd1588:0x1c 0xdf 0x92 0x9d 0xfe 0x41 0x59 0xfa0xbd1590:0x6e 0x2a 0x99 0x18 0x5f 0x1d 0x2a 0x480xbd1598:0x99 0xaf 0x31 0x68 0x1e 0x36 0xc8 0x750xbd15a0:0x3f 0xe2 0x29 0x36 0x53 0xb7 0x8e 0x8c0xbd15a8:0xa2 0x9a 0x9b 0x39 0x3c 0x18 0x94 0x1a0xbd15b0:0x0e 0x92 0xd5 0x1b 0x60 0xc7 0x13 0x600xbd15b8:0x8a 0xb9 0x0b 0x31 0x95 0x6d 0x46 0x190xbd15c0:0x40 0xa9 0x89 0x4e 0xc4 0x6d 0x26 0x740xbd15c8:0x77 0xfe 0x5b 0x90 0xb1 0x5d 0xa9 0x790xbd15d0:0xce 0xed 0x52 0x4d 0xbe 0x17 0xcc 0x370xbd15d8:0x87 0xcd 0xfa 0xd9 0x4e 0x3d 0xb1 0x55其中一个素数的数据就在这个内存块的中间。一个令人困扰的问题是，当OpenSSL具有清理内存的功能时，为什么这些密钥块会在内存中找到。我们正在继续调查，如果发现一个bug，将提交一个OpenSSL的补丁。服务器提供的HTTPS流量越大，这些中间值中的一些最终出现在Heartbleed可以读取它们的堆中的可能性就越大。不幸的是，我们的测试服务器在本地机器上，没有大量的HTTPS流量。这使得我们在实验环境中找到私钥的可能性大大降低。CloudFlare Challenge站点提供了大量的流量，因此更有可能提取密钥。我们还从获奖者那里学到了一些在内存中高效地找到钥匙的诀窍。为了解释这些，我们将深入了解RSA的工作原理。RSA密码体制RSA密码体制的基础是选取两个素数（通常称为p和q），然后利用素数的各种数学性质来创建一个安全系统。首先计算一个数n（称为模数）。它只是p x q。RSA中的另外两个重要值被称为指数，通常称为e和d。在普通RSA密码系统中，e是65537。公钥是（n，e）（即模和指数e），私钥是（n，d）（即模和指数d）。当然，质数p和q也必须保密，因为一切都取决于它们。在教科书RSA中，你可以只使用d和n来执行私钥操作，但是速度很慢。在OpenSSL中，RSA的私钥操作还使用素数p和q来加速私钥操作，使用Montgomery算术和其他技巧。如果找到了p或q，它们就可以用来导出私钥d。搜索p和q是大多数成功参赛者采用的方法。从随机数据中识别素数因子最常见的技巧是获取与素数因子大小匹配的所有数据块（2048位RSA密钥为128字节）并将其转换为数字。一些参赛者做了一个素数检查，看看这个数是否素数，还有一些参赛者试图将这个数除以公模n。如果这个数是一个素数因子，那么它就可以用来提取私钥d。这是Fedor Indutny在其博客上发表的方法。徐鲁宾采取了第二种更为优雅的方法。他一开始试图寻找基本因子，但很快就放弃了寻找它们。然后他决定用铜匠的攻击来推导私人指数。在这种攻击中，只需要私钥的一部分，然后用数学方法重建私钥。这次攻击非常有效，他只从前50个转储中提取了私钥！优胜者以下是挑战赛的赢家，按他们找到私钥的时间顺序排列：Fedor Indutny（@Indutny）开发者Ilkka Mattila，信息安全顾问徐鲁宾（@xurbin），安全学博士生Ben Murphy（@benmmurphy），安全研究员史蒂夫·亨特（@nonxiomatic）Xavier Martin（@xav），安全研究员没有名字Jeremi Gosney（@jmgosney），Stricture Group首席执行官Michele Guerini Rocco（@Rnhmjoj），学生David Gervais（@davidgervais），软件工程师克里斯蒂安·布尔吉（@buergich）丹尼尔·伯克德（@hiptomcat）曼查姆加梅拉向他们所有人致以热烈的祝贺！调查结果基于这些发现，我们认为，一个专用攻击者可以在两小时内从易受攻击的服务器检索私钥。由于临时密钥材料的分配是由OpenSSL本身完成的，并且不是NGINX所特有的，所以我们希望这些攻击能够在不同的服务器软件上工作，包括使用OpenSSL的非web服务器。运行使用易受攻击的OpenSSL版本的服务器的所有管理员都应使用版本1.0.1g（或更高版本）修补OpenSSL，并重新颁发和吊销其所有私钥。如上所述，CloudFlare现在已经为我们代表他们管理SSL的所有客户做到了这一点。作为Heartbleed bug和CloudFlare挑战赛的后续行动，我与Fonix的Ben Murphy举办了一次网络研讨会。本是CloudFlare心血挑战赛的赢家之一。我和本回答了很多问题；这次网络研讨会的录音发布在CloudFlare的YouTube频道上，可以在下面看到。