这应该是处理 Heartbeat 漏洞的典型问题。
我使用 OpenSSL 运行 Apache Web 服务器，以及其他一些依赖 OpenSSL（作为客户端）的实用程序。我应该怎么做才能降低风险？
I looked at some of the data dumps
from vulnerable sites,
and it was ... bad.
I saw emails, passwords, password hints.
SSL keys and session cookies.
Important servers
brimming with visitor IPs.
Attack ships on fire off
the shoulder of Orion,
c-beams glittering in the dark
near the Tannhäuser Gate.
I should probably patch OpenSSL.
学分：XKCD。
对于每个受影响的服务器，需要考虑的不仅仅是新证书（或者更确切地说是新密钥对）。这也意味着：
Neel Mehta（最先报告该漏洞的谷歌安全工程师）在推特上写道：
堆分配模式使得#heartbleed #dontpanic 不太可能暴露私钥。
Tomas Rzepka（可能来自瑞典安全公司Certezza）回复说他们必须做些什么来恢复密钥：
重启 apache 并使用 ssltest.py 发出第一个请求后，我们可以在 FreeBSD 上成功提取私钥
CloudFlare Challenge也证明了私钥被盗。
我已经从 Gentoo 上的 Apache 恢复它作为二进制文件中的一个主要因素，但你的演示更清晰......它的成功率很低，在同一连接上进行更多尝试没有帮助，重新连接可能，重新启动可能赢了't...具有良好堆利用技能的人可能会提高可靠性。我真的没有那么努力。
我从heartbleed.com总结了上面的要点（强调我的）：
什么是泄露的主键材料，如何恢复？
这些是皇冠上的宝石，加密密钥本身。泄露的密钥允许攻击者解密任何过去和未来到受保护服务的流量，并随意冒充服务。可以绕过 X.509 证书中的加密和签名提供的任何保护。从此泄漏中恢复需要修补漏洞、撤销受损密钥以及重新发布和重新分发新密钥。即使做所有这些仍然会使过去被攻击者拦截的任何流量仍然容易被解密。所有这些都必须由服务的所有者完成。
什么是泄露的二级密钥材料，如何恢复？
例如，这些是易受攻击的服务中使用的用户凭据（用户名和密码） 。从此泄漏中恢复需要服务的所有者首先根据上述步骤恢复对服务的信任。在此之后，用户可以根据受到损害的服务所有者的指示开始更改他们的密码和可能的加密密钥。所有会话密钥和会话 cookie 都应无效并被视为已泄露。
什么是泄露的受保护内容以及如何恢复？
这是易受攻击的服务处理的实际内容。它可能是个人或财务详细信息、私人通信（如电子邮件或即时消息）、文档或任何值得通过加密保护的东西。只有服务的所有者才能估计泄露的可能性，他们应该相应地通知用户。最重要的是恢复对如上所述的主要和次要密钥材料的信任。只有这样才能在未来安全使用受感染的服务。
什么是泄露的抵押品以及如何恢复？
泄露的抵押品是在泄露的内存内容中暴露给攻击者的其他细节。这些可能包含技术细节，例如内存地址和安全措施，例如用于防止溢出攻击的金丝雀。这些只有当代价值，当 OpenSSL 升级到固定版本时，它们对攻击者将失去价值。
处理 TLS 心跳扩展时的缺失边界检查可用于向连接的客户端或服务器显示多达 64k 的内存。
只有 OpenSSL 的 1.0.1 和 1.0.2-beta 版本受到影响，包括 1.0.1f 和 1.0.2-beta1。
感谢 Google Security 的 Neel Mehta 发现了这个错误，感谢 Adam Langley 和 Bodo Moeller 准备修复。
受影响的用户应升级到 OpenSSL 1.0.1g。无法立即升级的用户也可以使用 -DOPENSSL_NO_HEARTBEATS 重新编译 OpenSSL。
1.0.2 将在 1.0.2-beta2 中修复。
检查您是否使用上述版本的 OpenSSL，如果是，则将其修补到 1.0.1g（通过从源代码编译并使用例如FPM包装包）。
（由 atk 添加）然后，替换您公开的证书并吊销它们。
（由 dr.jimbob 补充）值得指出的是，OpenSSH 不受 OpenSSL 错误的影响。虽然 OpenSSH 确实将 openssl 用于某些密钥生成功能，但它不使用 TLS 协议（尤其是心脏出血攻击的 TLS 心跳扩展）。因此，无需担心 SSH 受到威胁，尽管将 openssl 更新为 1.0.1g 或 1.0.2-beta2 仍然是一个好主意（但您不必担心替换 SSH 密钥对）。
（由 Deer Hunter 补充）：从DMZ中报告的积极尝试来看，现在最好的事情是尽快停止 FRIKKIN 服务器。会话被劫持，密码被泄露，机密商业数据被泄露。
（额外由 EFF.org 提供）：“要对 Heartbleed 的历史做出更明确的结论，网络社区最好尝试复制 Koeman 的发现。任何拥有大量 TLS 层流量日志的网络运营商都可以检查恶意心跳，最常见的 TCP 有效载荷为18 03 02 00 03 01 40 00or 18 03 01 00 03 01 40 00，尽管0x4000末尾的 可能被替换为较小的数字，特别是在尝试读取多个 malloc 块 bin 的实现中。” 简而言之，如果您保留详细的 TLS 日志（对于大多数运营商来说不太可能），请检查过去的利用尝试（并分享您所拥有的）。
ServerFault 上的相关问答：
https://serverfault.com/questions/587338/does-heartbleed-affect-aws-elastic-load-balancer
https://serverfault.com/questions/587329/heartbleed-what-is-it-and-what-are-options-to-mitigate-it
AskUbuntu 上写得很好的总结：https ://askubuntu.com/a/444905
Unix&Linux SE 的全面问答：https ://unix.stackexchange.com/questions/123711/how-do-i-recover-from-the-heartbleed-bug-in-openssl
如果您有机会在 Mac OS X 上运行服务器：https ://apple.stackexchange.com/questions/126916/what-versions-of-os-x-are-affected-by-heartbleed
使用 heart bleed 检索私有 SSL 密钥：http: //blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed 是的，这是可能的！
[编辑]
我制作了一个工具来检查您的 SSL 的状态，并查看心跳是否已启用且易受攻击。工具位于：http ://rehmann.co/projects/heartbeat/
在http://filippo.io/Heartbleed/还有一个
如果您容易受到攻击，请升级您的 OpenSSL 软件包并更新您的证书！
请注意，如果您使用的是基于云的提供商或内容分发网络，并且它们很容易受到攻击，您网站的泄露内容将与使用该提供商的所有其他网站的内容混合在一起。我刚刚在 Incapsula 中看到了这一点，银行网站的内容在加密货币网站上被泄露。幸运的是，它们现在已修复。