我一直在几台服务器上使用 Heartbleed 的 Python 实现，并获得了各种数据作为响应。
在收到的数据中，我看到：
- Cookies values (SESSIONID, etc)
- Random characters that make no sense
- HTML
- ...?
我知道我在这里是一个脚本小子，但无论如何，我想知道这些数据来自哪里（RAM？）哪些应用程序将数据放在那里（apache？openSSL？）并且通常希望更广泛地了解正在发生的事情.
有什么帮助吗？
根据heartbleed.com的说法，一个易受攻击的机器可以在每个心跳请求中泄漏 64kb 的内存内容，但攻击者可以任意多次发出这些请求。我已经看到了这样的评论，即攻击者理论上可以恢复足够的数据来完全重建目标机器的 RAM 内容——或者至少，无论 Apache（或 SSL 会话中涉及的任何程序）可以看到多少数据. 例如，这可能包括 cookie、正在提供的文件以及来自传入的数据——尤其是用户名和密码。
一个特殊的问题是，任何执行 SSL 的进程都需要有足够的信息来解密传入数据并签署传出数据——也就是说，私钥。泄漏会使您面临 MITM 攻击，并可能（并非总是）对截获的数据进行追溯解密。密钥泄漏未被检测到的可能性是为什么建议的响应是修补 OpenSSL然后重新生成密钥- 修补 OpenSSL 可以保护您免受未来的攻击，但您无法知道您的加密密钥是否已经被泄露。
在为传输层安全 (TLS) 设定标准的 RFC 5246 中，有一个称为心跳的功能。客户端和服务器来回发送一些数据以保持连接处于活动状态，以便以后使用。现在在实践中，客户端会发送一些数据，而服务器只会将其发回，一切都很好。然而，在受影响的 OpenSSL 版本中，没有检查客户端是否实际发送了它发送的数据量。因此，如果我发送 1B 并告诉服务器我实际上发送了 64kB，那么它会很高兴地给我发回 64kB。那些其他字节来自哪里？这就是那里的关键。OpenSSL 将向您发送回 64kB-1B 的内存，该进程可以访问并且您最初没有发送，具体取决于您的 1B 的存储位置。这些来自内存的额外字节是问题所在，因为它们可能包含有价值的信息，例如私钥材料和服务器正在解密以使用的信息。例如：密码、信用卡信息和/或 PIN。