哪些客户被证明容易受到 Heartbleed 的影响？
事实上，是的，客户很容易受到攻击。到目前为止，注意力都集中在服务器上，因为它们更容易被利用。（几乎）每个人都可以连接到公共 HTTP/SMTP/... 服务器。
该博客描述了该错误的实际工作方式（它提到了dtls_process_heartbeat()，但tls_process_heartbeat()以相同的方式受到影响）。该函数同时用于客户端和服务器应用程序，因此客户端也应该是易受攻击的。
根据 RFC 6520，握手期间不应发送心跳。实际上，OpenSSL 在发送 ServerHello 后立即接受心跳（这是 Jared Stafford 的 ssltest.py 所做的）。经过进一步测试，我发现服务器也可以通过在发送 ServerHello之后立即发送心跳来滥用客户端。它触发了相同的错误。
可以在我的仓库https://github.com/Lekensteyn/pacemaker中找到概念证明。从它的自述文件中：
以下客户端已针对 1.0.1f 进行了测试，并在握手前泄漏了内存：
- MariaDB 5.5.36
- wget 1.15（泄漏早期连接和自身状态的内存）
- curl 7.36.0 (https, FTP/IMAP/POP3/SMTP with --ftp-ssl)
- git 1.9.1（测试克隆/推送，泄漏不多）
- nginx 1.4.7（在代理模式下，泄漏先前请求的内存）
- 链接 2.8（泄露以前访问的内容！）
- KDE 4.12.4（kioclient，Dolphin，用 kde4-ftps-kio 测试过 https 和 ftps）
- Exim 4.82（传出 SMTP）
已经证明确实可以返回 64 KiB 的内存（65535 字节）。还证明了客户端（wgetKDE Dolphin，...）可以像以前的请求一样泄露数据，可能包含密码。
我写了一个 Metasploit 模块来测试它，它目前正在审查中，但应该很快就会到达 master 分支。此时第一个版本被合并到主分支中。
与服务器端攻击不同，您必须实施大部分 TLS，因为心跳回复是根据 SSL 会话密钥加密的。我使用 wget、curl 和 openssl 命令行进行了测试。一个有趣的消息是针对 wget 和 openssl(1)，无论证书验证如何，攻击都会成功。curl 二进制文件需要 -k 或有效证书以使会话保持足够长的时间以使攻击起作用。针对这些相对综合的测试，我可以可靠地泄漏 TLS 会话密钥（AES-128-CBC），但这并不能提供太多，因为服务器在握手期间知道相同的密钥。
EDIT1：看起来起搏器代码无需进行完整的 TLS 握手即可完成此操作（甚至更好！）。我会对人们在实现之间可能拥有的任何测试结果感兴趣。IOW，在客户端因自签名证书而断开连接的情况下，起搏器是否成功？
EDIT2：@Lekensteyn 在起搏器中使用的方法（在服务器问候之后发送心跳）是一种更好的方法，因为 CA 验证不是问题。我提交了一个新的 Metasploit PR，它默认为此模式并使用 NEGOTIATE_TLS 选项保留 TLS 协商代码路径（为旧模式设置 NEGOTIATE_TLS true）。给@Lekensteyn 的道具！
可以利用客户端中的错误。该测试器可用于向任意客户端发出“邪恶”URL，并查看他们是否上钩。我发现 3 个前 100 个网站（我不会在这里命名）使用截至 2014 年 4 月 9 日易受攻击的客户端获取 URL。
如果您有 Android 设备，则可以安装其中一款用于测试漏洞的 Heartbleed 应用程序，如下所示：
https://play.google.com/store/apps/details?id=com.lookout.heartbleeddetector
我在两部 Android 手机上对此进行了测试，一部是 4.3，一部是 4.4，两者都报告为易受攻击，但两者都没有使用 OpenSSL，所以一切都很好......
所以一切正常。太好了，没有应用程序使用 OpenSSL。但是，如果我安装了一个使用它的应用程序怎么办？我会收到通知吗？我猜不会！
4.4的手机是索尼全新的，第一次使用后下载了系统更新，但我想这还不足以修复？！