隐藏OpenSSL专用密钥
隐藏OpenSSL辅助密钥
从以下位置检索最多64kb的内存受影响的服务器
因此，请解密服务器与客户端之间的所有流量
修复此问题的对OpenSSL的提交在这里
有点不清楚-我读过的所有内容都包含有关应采取的措施的信息，而不是其工作方式的信息。那么，这种攻击如何起作用？
#1 楼
这不是TLS中的缺陷。这是OpenSSL中的一个简单的内存安全性错误。到目前为止，我遇到的最好的解释是博客文章，作者Sean Cassidy的《 OpenSSL Heartbleed Bug的诊断》和《本周的攻击：OpenSSL Heartbleed》 Matthew Green。
简而言之，Heartbeat允许一个端点进入“我正在向您发送一些数据，并将其回显给我”。您发送长度图和数据本身。长度最多可以达到64 KiB。不幸的是，如果您使用长度数字声明“我正在发送64 KiB数据”（例如），然后仅实际发送一个字节，则OpenSSL会向您发送一个字节-64 KiB（减去一个）来自RAM的其他数据。
这允许另一个端点使用OpenSSL从进程中获取内存的随机部分。攻击者无法选择哪个内存，但是如果尝试了足够的时间，他们的请求的数据结构可能会紧随有趣的事物（例如您的私钥或用户的Cookie或密码）之后出现。
无除非您记录所有原始TLS连接数据，否则此活动的日志将记录在任何地方。
不好。
上面的xkcd comic可以很好地说明问题。
编辑：我在下面的评论中写道，心跳消息已加密。这并非总是如此。您可以在TLS握手的早期发送心跳，而无需打开加密（尽管您不应该这样做）。在这种情况下，请求和响应都不会被加密。在正常使用情况下，应始终将心跳发送后进行加密，但是大多数漏洞利用工具可能不会费心完成握手并等待加密。 （感谢RedBaron。）
评论
具有由用户提供的未经检查的长度参数的memcpy，这是C语言中最常见的安全性错误之一。这是一个可悲的奇迹，因为在如此广泛部署的软件（如OpenSSL）中，人们并没有这么长时间才注意到。
– Philipp
2014年4月8日13:27
@Philipp直到现在都没有发现并报告过。过去两年来，眼神敏锐的情报机构一直在利用它，这似乎是有道理的。
–马特·诺德霍夫（Matt Nordhoff）
2014年4月8日13:38
@ArunMu是的，它将被加密。您可以放心，攻击者将安全地下载您的RAM。 :-P除了已经窃取了您的密钥的其他攻击者之外。
–马特·诺德霍夫（Matt Nordhoff）
2014年4月8日14:47
尽管这不是TLS扩展或TLS协议中的缺陷，但TLS规范仍在某种程度上负责。记录内消息的分层，以及您在记录内通常具有多个长度规范这一事实，这是非常脆弱的协议设计，并带来麻烦。更糟糕的是，当实现不使用安全的辅助方法抽象化分段并进行解析（因此所有扩展解析器都需要重新设计轮子时）。
–eckes
2014年4月8日在17:17
@RedBaron半空中碰撞！ RFC表示在握手过程中发送了“ SHOULD NOT”心跳，而接收者“ SHOULD”则将其丢弃。允许实现不遵从“ SHOULD”，否则将是“ MUST”。
–马特·诺德霍夫（Matt Nordhoff）
2014年4月9日10:00
评论
该视频说明非常好vimeo.com/91425662可以在这里找到解决Heartbleed错误的另一篇有用的博客文章：cloudishvps.com/linux/…，它还提供了在CentOS和Ubuntu上升级OpenSSL的步骤。
视频安全公司Elastica的首席技术官Zulfikar Ramzan制作了此视频，它在相当高的水平上很好地解释了该错误。他还为可汗学院录制了许多视频。 Vimeo：OpenSSL心跳（严重故障）漏洞（CVE-2014-0160）及其高级机制感谢TechCrunch的Greg Kumparak提供的链接。
我只是对漏洞利用的工作方式感到好奇，视频很好地说明了这一点，您一定要检查一下。
最新的xkcd有一个简单的解释：xkcd.com/1354