大量的。巨大。灾难性的。这些都是我今天看到的头条新闻，基本上说我们现在在互联网安全方面真的完蛋了。但具体来说这:
心跳错误允许互联网上的任何人读取受易受攻击的OpenSSL软件版本保护的系统的内存。
在安全的世界里，时不时会发生一些相当严重和广泛的事情，我们都像无头小鸡一样到处乱跑，想知道这到底意味着什么。国家安全局最终“抓住我们”了吗？SSL死了吗？天塌了吗？嗯，它是坏的，但并不是对每个人都适用，也不可能像许多人所说的那样糟糕。大多数早期消息都已传出心痛.com（由创建的网站Codenomicon公司)如果我可以这么说的话，它在建立一个非常漂亮的小网站和为错误打上品牌方面做得很好：
但事实上，它比闪亮的标志所暗示的要复杂得多。这并不是一个容易理解的概念，仅仅这一点就加剧了人们对错误真正是什么、错误是什么的困惑和猜测不是也许最重要的是，你需要做些什么。我将尝试将这个问题提炼成人们正在问的一系列常见问题——如果你愿意的话，简而言之就是心碎。
什么是OpenSSL？哪些版本受到影响？
让我们从这里开始：心跳错误只存在于开放源码软件SSL和TLS的实现（请注意，尽管并非总是相同的东西，但这些首字母缩写词往往可以互换使用通常指的是它们在HTTP或HTTPS上的实现）。顾名思义，这是一个开源软件产品，有助于通过SSL协议进行通信极其通用。披露时，关于据说世界上17%的“安全”网站容易受到该漏洞的攻击.
通常，OpenSSL实现存在于运行Apache和nginx的服务器上。不幸的是，Apache仍然是当今的主流web服务器超过一半的互联网活跃网站都在上面运行nginx还有大约14%：
事实上，心脏出血漏洞本身是在2011年12月引入的它似乎是在除夕前一个小时发生的（你会怎么读）。该错误影响了OpenSSL版本1.0.1，该版本于2012年3月发布，一直到今年1月6日发布的1.0.1f。这个时机的不幸之处在于只有在你做了“正确的事情”并保持版本更新的情况下，你才容易受到攻击！再说一次，对于那些认为你需要花一点时间发布新版本，以便在采用它们之前消除错误的人来说，他们真的会预计需要两年以上的时间吗？可能不会。
编辑：请注意，如果您正在运行贝塔OpenSSL 1.0.2版也易受攻击。
是否只有Apache和nginx上的站点受到影响？
并非所有web服务器都依赖于OpenSSL。例如，IIS使用Microsoft的SChannel实施，其中不是冒着这个错误的风险。这是否意味着IIS上的站点不易受到心跳信号的攻击？在大多数情况下，是的，但不要太自负，因为OpenSSL可能仍然存在于服务器场中。一个恰当的例子：来自Stack Overflow的Tim Post今天早些时候在推特上发表了这篇文章：
但他们不是在运行所有ASP吗。IIS上的NET MVC？是的，他们当然是，这在尼克·克雷弗去年的精彩帖子中非常清楚通往SSL的道路，实际上，您可以看到（IIS）web服务器都位于此图像的右侧：
等等，里面也有nginx吗？？？是的，关于这个：
HTTPS流量到达负载平衡器机器上的nginx并在那里终止。
你看到问题了吗？是的，他们可能正在使用IIS，但不，这并不意味着OpenSSL没有在他们的服务器场体系结构中发挥作用，事实上，它位于所有其他终止SSL的东西的前面。如果作为反向代理的机器位于IIS前面并运行Apache或nginx，也会出现相同的问题。
编辑：来自Stack Overflow的Nick和Ben已澄清他们现在使用HAProxy终止SSL它使用…OpenSSL。
这是另一个，事实上，我昨晚从AppHarbor收到了关于ASP的消息。我随身携带的NET主机：
重点是经常服务器基础设施不仅仅是web服务器本身有意识地在Apache或nginx上运行并不意味着它在您的环境中不起作用。
是谁发现的，为什么要公开？
该漏洞的第一个公开证据是OpenSSL公告4月7日，并警告“处理TLS心跳扩展时缺少边界检查”。Google Security的Neel Mehta发现并报告了该漏洞，并简单说明了受影响的版本，建议升级OpenSSL，如果不可行，则重新编译并禁用心跳。
至于它为什么被公开，这是一场由来已久的争论，争论的焦点是公开披露是加快了补救措施，还是让脆弱的系统面临攻击。可能两者兼而有之，与网站上的单个离散漏洞相比，这种风险的问题在于，为了修复它，您需要大量使用修订版本，直到风险社会化，这是不会发生的。然后，你会遇到这样的问题，即只有一方怀着恶意的意图，开始对完全不知道风险的网站肆无忌惮地进行攻击，你就会得到一个真正地严重问题。
无论如何，你不能对现在的焦点或速度提出异议许多的目前正在修复易受攻击的网站。当然，还会有其他人落后，他们将面临严重的风险，让我们看看这对他们意味着什么。
什么是SSL心跳？
让我们首先了解一下这个bug的功能。我们在这里讨论的错误存在于OpenSSL的心跳扩展实现中，心跳扩展是一个特性IETF描述如下:
心跳扩展为TLS/DTLS提供了一种新的协议，允许在不执行重新协商的情况下使用keep-alive功能，并为DTLS的路径MTU（PMTU）发现提供了基础。
换言之，这是一种心跳，与我们在计算机系统的其他方面通常所知的心跳一样，也就是说，它是一种检查，以查看对方是否仍在或是否已离开。当对方仍在时，心跳使对等方之间的上下文保持活动状态，因此称为“保持活动”。在SSL上下文中，客户端和服务器之间的初始协商具有通信开销，心跳通过确定对等方是否仍然“活动”来帮助避免重复。如果没有心跳，唯一的方法就是重新谈判，这相对来说代价很高。
如何利用风险？它是如何修复的？
已经有很多概念验证代码了，我特别喜欢拉胡尔·萨西（Rahul Sasi）在他的心跳病POC和大规模扫描器中的例子他清楚地解释了易受攻击的代码、修复程序以及他为测试bug而编写的内容。简而言之，OpenSSL中的原始风险都归结为以下代码行：
缓冲区=OPENSSL_malloc（1+2+有效载荷+填充）；
正如拉胡尔所解释的：
在上述代码中，内存是从有效负载+填充中分配的，具有用户控制的值。没有对此特定分配进行长度检查，攻击者可以强制Openssl服务器读取任意内存位置。
换句话说，攻击者可以控制心跳大小并将其结构设置为大于预期，在端口443上使用TCP将其发送到目标服务器，并接收一个响应，该响应在超出心跳界限的内存分配中包含高达64kb的数据应该能够访问。使用不同的心跳大小再次执行此操作，从另一个内存空间获得另一个64kb的响应。清洗，冲洗，重复。很简单。
您可以去检查代码和随后的修复在此GitHub上提交如果您想深入了解本质，但简而言之，有效负载现在已“绑定检查”（不能超过16个字节），并且现在已验证整个心跳，以确保其不超过允许的最大长度。最终，这归结为一个非常简单的错误，它出现在一小段代码中，需要很小的修复。现在，它只需要安装在50万个易受攻击的网站上。
风险是什么？如果它被利用了，会出什么问题？
让我们从技术描述开始维基百科提供:
TLS心跳扩展处理中的丢失边界检查可用于向连接的客户端或服务器显示多达64k的内存
好的，但这实际上意味着什么？这意味着攻击者可以这样做：
如果这件事的严重性尚不清楚，这里断言的是Mark能够读取其他用户的凭据（在本例中为“agnesaduboateng@yahoo.com“以及他们的密码（已被模糊处理）直接从雅虎服务的内存中提取，而他只是通过发出SSL心跳信号远程完成了这一切。哇哦。
更具体地说，我们正在研究是对Yahoo网站的加密HTTPS请求（不可避免地是对登录页面的POST请求），当Mark进行攻击并提取数据时，我们看到该请求的一个组件仍驻留在内存中。那么，攻击者还可以通过此漏洞获得哪些其他访问权限？凭证是一回事，但当然这只是因为它们占用了内存空间，而内存空间中必然只有一段数据。另一个是会话ID或身份验证令牌；即使你不能通过bug提取用户的凭据（当时它必须仍在内存中），你仍然可以提取在请求之间保持会话的ID，从而使攻击者能够劫持该会话并冒充用户。
其他的真正地可以提取的重要数据是证书的私钥。我要准确地重复一下心痛.com总结泄漏的主键材料，因为他们总结得如此雄辩：
这些是王冠上的珠宝，加密密钥本身。泄漏的密钥允许攻击者解密任何过去和未来到受保护服务的流量，并随意模拟服务。X.509证书中的加密和签名提供的任何保护都可以绕过。要从该泄漏中恢复，需要修补漏洞，撤销受损密钥，并重新发布和重新分发新密钥。即使这样做，仍然会使攻击者过去拦截的任何流量仍然容易解密。所有这些都必须由服务所有者完成。
不要错过关于过去拦截的那篇文章的严肃性；私钥的公开提供了解密数据的机会以前甚至在这个漏洞被发现之前就通过网络发送了。如果有人一直在储存这些pcap（*咳嗽*NSA*咳嗽*）和然后他们就可以利用这个bug来获取密钥，您以前的所有数据都属于他们。
它可以就那么糟糕。从理论上讲，但事实是：
还记得内尔吗？是的，他是一开始就发现错误的人。他是对的，其他人都错了吗？也许 吧。也许不是：
Codenomicon怎么样？还记得吗？他们创造了心痛.com我一直提到的网站已经成为了这个bug的标准参考。
无论密钥是否可以远程访问，仍然有其他所有可寻址内存导致暴露的凭据和会话ID。然后在HTTPS通信中还有所有其他数据真正地不想被远程匿名访问，问题是这个bug是否也会损害证书本身，而且已经足够了有人窃窃私语说他们已经做到了做最坏的打算，抱最好的希望。
如何判断网站是否易受攻击？
远程测试的最简单方法是跳到心脏出血测试页面由创建菲利波·瓦索尔达。易受攻击的站点如下所示：
好的，那么我们在看什么？菲利波很友善在GitHub上开源代码这样我们可以往里面看一看。简而言之，他只是将字符串“YELLOW SUBMARINE”添加到心跳的填充中（请回到Rahul Sasi的前一篇文章以了解上下文），发送心跳，然后观察它是否出现在响应中。还有更多，但你明白了。
为什么花了两年时间才发现风险——开源不是“安全的”吗？！
理论是这样的——“开源软件更安全，因为社区可以更早地对其进行检查和识别错误”。当然，这句话的关键词是可以，不是将.
这个GitHub上的OpenSSL项目拥有超过10000个提交，跨越21个贡献者和25个分支，跨越57MB的源代码。它不是很大，但里面已经足够了，而且这个错误也够模糊的了回顾过去直到现在才被注意到。我们认为——也许其他人早就注意到并利用了它。说到这里…
NSA/GCHQ/俄罗斯黑手党参与了吗？
对。下一个问题？
然而，严肃地说，我们现在已经了解到政府将在多大程度上拦截和解密私人通信集体且无目标（不要认为这只是美国在做的事情，我们已经忘记中国等了吗？！），你能想象这对执行大规模数据包捕获的组织有多大吸引力吗？如果真的有可能从服务器远程提取私钥，这将是一个绝对的金矿，比我们现在知道的政府正在做的事情要容易得多。
政府是一回事，职业罪犯呢？关于这种风险，令人担忧的一件事是它很容易实现自动化。我们已经看到了这种情况的发生，既有好的一面（大规模测试组织的网络资产），也有坏的一面（大量测试另一个组织的网络资产）。它可以远程、快速地完成，并且可以通过多个主机进行枚举，这使得它更具吸引力。如果罪犯还没有将其武器化为大规模数据过滤工具，我会非常惊讶。
重新颁发证书能解决问题吗？
是和否。首先，在你第一次修补运行OpenSSL的服务器之前，这样做是没有意义的，否则你只是把一个全新的证书置于危险之中。
接下来，如果您假设易受攻击站点上的私钥已被泄露（如果您谨慎的话，这是最安全的假设），那么应该重新颁发证书旧的被撤销了。但撤销存在问题–请查看Chrome的默认设置：
是的，Chrome中没有对吊销证书的默认检查。Internet Explorer如何：
是的，这是默认设置，自IE7以来一直是这样。当然，Chrome现在在浏览用户中占据了最大份额，因此，在存在易受攻击的OpenSSL版本的情况下，重新发布证书并撤销旧证书是一个很好的举措，但这并不一定会阻止客户信任已撤销的证书。糟糕透了。
但是，除了验证（或不验证）撤销证书的技术逻辑之外，还有成本影响。通常，证书要花钱。有时证书撤销要花钱。作为朋友和全面聪明的保安凯西·埃利斯今天早上说，现在有很多认证供应商都在做这件事：
很少有严重的安全事件会给安全行业的参与者带来巨大的机会。
你如何判断自己是否已经受到威胁？
是的，关于这个-你不能简单地在普通日志中寻找妥协的痕迹。再次从心痛.com:
利用此漏洞不会留下日志发生任何异常的痕迹。
问题是，这个bug并没有通过通常会被记录的通道被利用。例如，如果您受到SQL注入漏洞的攻击，那么您的web服务器日志中充满了危险的HTTP请求。当然，这也提出了一个非常令人不安的问题：如果你的网站易受攻击，你会假设自己受到了威胁吗？
要使攻击成功，需要有一系列的因素（请参阅本博客的最后一节），但无论如何，这将使许多公司非常当他们知道开发潜力和如何进行开发的知识都存在时，他们的处境很棘手。以雅虎为例，他们应该根据马克的例证做什么？强制每个人重置密码？告诉客户他们的数据可以已经妥协了？对他们来说，这是一个非常非常冒险的局面。
入侵检测/保护系统能够识别攻击吗？
可能是这样，我已经看到证据表明这种情况可能已经发生，而且各种IDS提供商也开始吹嘘阻塞功能。例如，Bro Network Security Monitor声称:
兄弟可以检测到这次攻击以几种不同的方式。在最简单的化身中（这是我们迄今为止在野外看到的唯一一个化身），心跳消息在TLS加密开始之前很早就发送了。
在这些情况下，Bro只是比较有效负载和消息大小。如果存在不匹配，我们就知道有人试图利用它。如果服务器响应消息，则很可能会受到攻击。
当然，过度热情的IPS（入侵保护系统，如用鼻子哼哼)可能会完全阻止心跳请求（风险心痛.com但坦白地说，如果站点确实容易受到风险的影响，那么这是一个不错的位置，其最终结果与在禁用心跳的情况下重新编译OpenSSL相同。是的，这可能会对你的表现造成一点不愉快的影响，但可能的替代方案要糟糕得多。
如果您正在运行IPS和你还没有能够修补潜在的风险，那么就有必要看看签名是否可以在过渡期间缓解这个问题。
除了HTTPS之外，还有什么影响？
任何具有OpenSSL依赖性的东西都可以包括VPN实现、即时消息客户端、电子邮件和其他我几乎肯定没有想到的东西。仅仅因为你在地址栏中没有看到HTTPS并不意味着你没有风险。
完美远期保密解决了所有这些问题吗？
是的，但不是回顾性的，只是暴露密钥的潜在风险，而不是内存内容暴露的情况。关于前向安全性就是暴露一把钥匙不应该让整个纸牌屋崩溃：
公开密钥系统在每个会话中生成随机公开密钥，用于密钥协商，而不是基于任何类型的确定性算法，其特性称为前向安全性这意味着一条消息的妥协不会导致其他消息的妥协，也意味着没有一个单独的秘密值可以导致多条消息的让步。
在心跳的上下文中，如果私钥可以从记忆中提取它不会导致每一条消息都被破坏，因为它们是唯一键控的。但是，这是你现在为未来准备好的东西，这不是解决心跳的方法，现在已经太晚了。
我是系统管理员，我该怎么做？
如果您负责维护网站运行的基础设施和web服务器，那么有一个明确的立即步骤：将OpenSSL更新到1.0.1g版作为优先事项。如果这不可行，您可以重新编译OpenSSL并使用此开关禁用心跳：
-DOPENSSL_NO_后座
正如我之前解释的那样，心跳是有目的的，关闭心跳可能会对性能产生影响，所以只能将其视为权宜之计。
接下来的步骤取决于你的风险厌恶或偏执程度，取决于你如何看待它。这以及你所保护的信息的价值。这些步骤也可能是开发人员的领域，可能包括：
- 重新颁发任何受影响的证书
- 吊销任何受影响的证书
- 查看在IPS级别阻止恶意心跳请求的可用性
- 终止所有活动用户会话
- 强制重置任何用户帐户的密码
这是我从AppHarbor收到的关于我的网站托管的建议（尽管我在IPS上添加了这一点），虽然你可能会认为这是安全方面的错误，但你也可能会认为那正是我们现在应该做的。
我是开发人员，我该怎么做？
首先，确保您已经阅读了系统管理员的上一节。许多开发人员发现自己在做各种各样的事情理论上服务器领域的人手脚脏兮兮的，让所有的基础设施为我们其余的人工作。
作为一个努力弥合开发和安全规程之间差距的人，我感到沮丧的是，这个错误意味着我不能再简单地说“开发人员，专注于在web应用程序中实现SSL，不要担心底层协议”。当然，您仍然希望确保SSL配置得当，以便开始使用（Qualsys SSL实验室测试免费检查），但这不再是一个从一开始就正确处理的问题，然后继续专注于将cookie标记为安全，不通过HTTP加载登录页面等等。
我能给你的一个非常实用的建议就是：不要收集或储存你不需要的东西。我最近不得不处理一个涉及注册人宗教收集的事件，这是一条对许多人来说非常敏感的数据，而这是在一个外国，如果你的世界观与他们的世界观不一致，那么这个国家并不总是特别宽容。他们为什么需要它？他们没有，只是“当时看起来是个好主意”。你不能失去你所没有的，这种方法不仅可以保护数据不被Heartbleed暴露，还可以保护数据免受SQL注入攻击、不安全的直接对象引用、会话劫持以及其他可能利用客户数据的一大堆恶意行为的影响。
我运行在线服务–我该怎么做？
现在要考虑的是，如果攻击者能够获得用户凭据、敏感数据或劫持会话，他们会造成什么样的损害。如果攻击者以用户身份登录，他们可以访问什么？他们可以授权什么？然后他们能用这些信息做什么？
这里最大的问题之一是，你几乎肯定无法判断自己是否受到了威胁。你可以知道你是不是处于危险之中知道自己一直处于脆弱状态，但你只能猜测脆弱的窗口。你不知道攻击者是什么时候第一次意识到这种风险的——它只是在最近几天才被社交化，但它是两年多前引入的。即使只花了你几个小时就修补好了，你有足够的时间被利用吗？
在安全感是强制重置密码，并向客户解释可能发生了“事件”。这对你和你的客户来说都不是一个愉快的体验，在安全方面有意义的东西与对信任和一般用户体验的影响之间需要权衡。这将是一个逐个案例的决定，而且不容易。
我该告诉我的非技术朋友怎么做？
拿出锡箔帽子？关掉他们所有的东西？在荒岛上休息一下，直到事情平静下来？这是一种消费者不需要针对错误采取指导行动的情况，至少不需要以同样的方式，例如，最近iOS中的goto错误导致操作系统更新。他们不是在web服务器上修补坏的OpenSSL的人（尽管我们还没有看到这种风险是否会影响客户OpenSSL依赖项）。
另一方面，他们可以如果该漏洞导致他们的凭据或其他个人数据泄露，则需要采取措施。理想情况下，这将是由有理由相信可能存在妥协的网站向他们提供的建议，即如果他们足够积极主动地识别风险，并且（可以说）足够负责地建议客户采取预防措施。这也是一项只能执行的活动之后修补了易受攻击的站点并安装了新的证书&这是不好的，将一个闪亮的新密码放入一个仍可能暴露给攻击者的站点。
当然，它也为消费者提供了另一个有价值的提醒——唯一安全的密码是您无法记住的密码这是一首老歌，但前提不变；我们必须总是假设密码最终会被破解，密码必须既牢固又独特，这意味着将其保存在内存中–人类记忆–已退出。两个因素是另一个重要因素，您需要确保在每个可能的位置（Dropbox、GitHub、Evernote、Microsoft Live ID等）都启用了此功能。这并不能完全解决心跳加速的问题，但这关系到消费者可以在多大程度上影响心跳加速。
但是是吗真正地那么糟糕？接下来会发生什么？
为了使此漏洞能够成功利用，必须进行多种操作：
- 网站必须首先实现SSL–没有SSL意味着没有OpenSSL意味着不存在心跳错误。
- 该站点必须运行OpenSSL。这就排除了互联网的一大部分，包括大多数IIS网站。
- OpenSSL版本必须介于1.0.1和1.0.1f之间；任何较旧或较新的内容，都不存在错误。
- 攻击者需要能够访问处于风险环境中的某个位置，即从发现错误到提供商对其进行修补。
- 如果所有这些都符合，一定有什么原因有用且可回收袭击发生时的记忆。除了最休眠的站点外，其他所有站点都很可能出现这种情况。
- 但不管怎样现在的站点活动，如果攻击者以前有pcap流量（再次问候，NSA！），然后可以拉入私钥从网站上看，这是一个严重的问题。
当然，问题是，虽然第1点到第3点是可以明确定义的，但在大多数情况下，我们不知道第4点和第3点是否真的发生了。在修补之前，攻击者知道风险有多久了？然后他们能够访问服务器吗？当时记忆中有什么有用的东西吗？或者，他们可以针对以前的数据捕获使用排除的密钥吗？
现在还为时过早，接下来可能会发生许多不同的事情。一种可能性是，我们会看到受影响的站点请求重置密码；Mark向我们展示了雅虎的脆弱性，当然他们不能不现在要求人们重置密码？我也不想特别叫马克，很快拖网穿过巴氏合金箱显示了易受攻击站点的大量公共文档。或者穿上那些怎么样Alexa Top 10000的清单，这些清单都经过了测试，其中许多都是易受攻击的? 这是一个很大的列表，事实上密码重置已经发生了，我今天从AppHarbor收到了一个：
当然，另一个风险是，我们将看到从易受攻击的站点提取的凭据被利用。这可以采取多种形式；我们已经看到了高克泄密事件后推特上的Acai Berry垃圾邮件和许多明显地由于凭据被盗而导致更严重的事件。现在的问题是，每当帐户被窃取的凭据泄露时，人们都会问：“这些是通过心跳从易受攻击的站点弹出的吗？”？这个虫子可能有一条非常非常长的尾巴。
