重要的 SSL 安全漏洞
2014 年 4 月 7 日星期一，一个 OpenSSL 漏洞被披露，该漏洞被称为近期互联网历史上最严重的安全漏洞之一。 该漏洞称为 Heartbleed 漏洞，是在 OpenSSL 版本 1.0.1 中引入的。 自 2012 年 3 月以来，它一直在使用中，并使用 2014 年 4 月 7 日发布的 OpenSSL 版本 1.0.1g 进行了修补。 标记为 CVE-2014-0160 的问题在 此处详细描述 。
该漏洞允许任何攻击者读取易受攻击主机的内存，这意味着在具有易受攻击版本的 OpenSSL 的主机上使用的任何密钥都应被视为已泄露。 发行版一直在更新他们的软件包并推出更新，但用户需要下载最新的软件包并撤销任何基于不安全版本的先前密钥。
我们将向您展示如何使用安全版本的 OpenSSL 更新您的系统，撤销任何不安全的 SSL 证书，并测试您是否容易受到攻击。
更新您的系统
DigitalOcean 镜像正在更新以包含最新版本的 OpenSSL 包，因为它们由分发打包器提供。 更新软件包的最简单方法是更新整个系统。
在 Ubuntu 和 Debian 上，您可以通过键入以下内容进行更新：
sudo apt-get update sudo apt-get dist-upgrade
如果您 仅 想要升级受影响的软件包，而不是更新整个系统（仅在您有理由相信升级其他组件会破坏您的系统时推荐），您可以通过以下方式选择性地升级 OpenSSL 软件包打字：
sudo apt-get install --only-upgrade openssl sudo apt-get install --only-upgrade libssl1.0.0
这将升级易受攻击的软件包，同时使系统的其余部分处于未升级状态。
在 CentOS 和 Fedora 上，你可以输入这个来更新整个系统：
yum update
如果您只想升级受影响的软件包，您可以发出以下命令：
yum update openssl
同样，仅当您有特定原因不更新整个系统时才建议这样做。
在撰写本文时（2014 年 4 月 8 日），Fedora 19 还没有稳定存储库中的最新版本。 您可以等待更新被接受，但您也可以继续手动构建包。 考虑到错误的严重性，这可能是值得的。
对于 64 位系统：
yum -y install koji koji download-build --arch=x86_64 openssl-1.0.1e-37.fc19.1 yum localinstall openssl-1.0.1e-37.fc19.1.x86_64.rpm
您可以通过键入以下内容对 Fedora 19 的 32 位系统执行相同操作：
yum -y install koji koji download-build --arch=i686 openssl-1.0.1e-37.fc19.1 yum localinstall openssl-1.0.1e-37.fc19.1.i686.rpm
在 Arch Linux 上，可以通过键入以下命令来更新软件包：
sudo pacman -Syu
如果您有选择地更新软件包，Arch Linux 系统可能会变得非常不稳定，因此我们不建议您只更新 OpenSSL 软件包。
如果您指向的镜像已经提取了最新的软件包，这应该会提取所有最近的更新，包括 OpenSSL。 您应该在升级包列表中看到 openssl 或一些变体。
完成后，您应该重新启动计算机以确保您的服务器没有使用内存中加载的旧版本。 您可以通过发出以下命令来做到这一点：
sudo shutdown -r now
检查您的版本号
更新系统后，您应该检查 OpenSSL 的版本。
虽然 OpenSSL 版本 1.0.1g 是此问题的官方修复程序，但针对不同发行版和发行版修复此问题的版本可能会有所不同。 一些发行版和发行版修补了他们的旧版本来解决问题，而不是把一个全新的版本发布到一个旧的、稳定的生态系统中。
由于这个原因，最好检查您的发行版的打包系统，因为 openssl version 命令可能无法反映我们需要的信息。
Debian 和 Ubuntu 发布和修复版本
对于 Debian 和 Ubuntu 系统，您可以通过键入以下命令获取 OpenSSL 包的当前版本：
dpkg -l | grep "openssl"
您应该收到如下输出：
ii openssl 1.0.1e-2+deb7u6 amd64 Secure Socket Layer (SSL) binary and related cryptographic tools
对于 Debian 用户，您正在运行的 Debian 版本将确定修复的正确版本。 如果您的 OpenSSL 版本是 至少 与此处列出的用于您的发行版的版本一样，您应该受到保护：
- Debian 6 (Squeeze)：不受影响（在漏洞之前与旧版本一起提供）
- Debian 7 (Wheezy): 1.0.1e-2+deb7u6
- Debian 测试 (Jessie): 1.0.1g-1
- Debian 不稳定 (Sid): 1.0.1g-1
对于 Ubuntu 用户，正确的补丁版本也取决于版本。 使用此列表查看您的版本的最低安全版本：
- Ubuntu 10.04：不受影响（在漏洞之前与旧版本一起提供）
- Ubuntu 12.04：1.0.1-4ubuntu5.12
- Ubuntu 12.10：1.0.1c-3ubuntu2.7
- Ubuntu 13.04：支持生命终结，应该升级
- Ubuntu 13.10：1.0.1e-3ubuntu1.2
如果您使用的是受支持的发行版之一，请确保您的 OpenSSL 版本是最新的。 如果您的发行版不再受支持（Ubuntu 13.04），由于此错误的严重性，强烈建议您转换到受支持的操作系统。
CentOS 和 Fedora 发布和修复版本
对于 CentOS 和 Fedora 系统，您可以通过键入以下命令来查询系统上安装的 OpenSSL 软件包的版本：
rpm -q -a | grep "openssl"
您应该收到如下所示的输出：
openssl-1.0.1e-16.el6_5.7.x86_64
对于 CentOS，以下是必须应用的 OpenSSL 发行版和最低版本，以保护未来的 SSL 交互。 我们将把架构放在列表的最后：
- CentOS 5：不受影响（在漏洞之前与旧版本一起提供）
- CentOS 6：openssl-1.0.1e-16.el6.5.7
对于 Fedora 用户，您可以检查您的软件包版本是否至少与下面列出的版本一样新。 同样，我删除了以下架构，因为这适用于 32 位和 64 位版本：
- Fedora 17：不受影响（与漏洞之前的旧版本一起提供）
- Fedora 19：openssl-1.0.1e-37.fc19.1
注意：密切关注Fedora版本号。 尾随的“.1”告诉您它是否已修补。 如果您的包裹末尾没有“.1”，那么您仍然很容易受到攻击！
Arch Linux 修复版本
如果您运行的是 Arch Linux，验证会容易得多，因为没有多个版本。
您可以检查已安装的 OpenSSL 版本：
pacman -Q | grep "openssl"
您应该收到如下所示的输出：
openssl 1.0.1.g-1
如果您安装的版本是此版本或更高版本，则可以。
撤销和重新颁发您的 SSL 证书/密钥
如果您从提供商处购买了 SSL 证书，并且您在服务器上更新了 OpenSSL 软件包，则需要撤销旧密钥，并且必须重新颁发新密钥。 这是一个称为“重新输入密钥”的过程。
此过程非常依赖于颁发初始证书的 SSL 服务，但您应该在其管理界面中搜索类似于“rekey”或“reissue keys”的选项。 大多数 SSL 颁发者会在您更新密钥时撤销您以前的密钥，但您通常也可以使用他们的管理界面显式执行此操作。
按照您的 SSL 提供商为您提供的说明进行操作。 他们可能会为您提供有关如何重新生成 CSR 的非常具体的说明，也可能不会。
如果他们没有为您提供他们希望您使用的特定 openssl 命令，您可以通过键入类似这样的内容来生成新的 SSL CSR。 同样，如果您不是 root，请添加 sudo：
openssl req -new -newkey rsa:2048 -nodes -keyout主机名.key -out主机名.csr
生成后，您需要将生成的 CSR 复制到提供商的 Web 界面中，以便为您的服务器重新设置密钥。 然后，您需要从 Web 界面下载新证书。
您必须将新密钥安装到保存旧密钥和证书的相同位置。 您需要用于证书和密钥的路径会因分布和您配置 Web 服务器的方式而异。 例如，一些保存在 /etc/ssl/certs 中，而另一些可能保存在您的 Web 服务器提供的位置。
例如，如果您使用的是 Apache Web 服务器，您应该在主 Apache 配置文件、虚拟主机文件或单独来源的配置文件中看到一行，该文件指向它查找 SSL 信息的位置：
SSLEngine on SSLCertificateFile /path/to/your_domain.crt SSLCertificateKeyFile /path/to/your_key.key SSLCertificateChainFile /path/to/CA.crt
这些可能看起来不同，但它们应该为您指明正确的方向，以找到您的 SSL 证书位置。
如果您使用的是 Nginx，您会发现类似的指令指向您的服务器的 SSL 证书和密钥。 它们可能看起来像这样：
server {
. . .
ssl_certificate /path/to/your_domain.crt;
ssl_certificate_key /path/to/your_key.key;
. . .
}
另一种选择是检查您的发行版的文档或检查您的服务器的文件系统以找出您的证书存储在哪里。
完成后，您应该重新启动 Web 服务器以使用新密钥。 执行此操作的方法因分发和服务器而异。
在 Debian 或 Ubuntu 上，您可以通过键入以下命令重新启动 Web 服务器：
sudo service apache2 restart # For Apache web server sudo service nginx restart # For Nginx web server
在 CentOS 或 Fedora 上，您可以通过键入以下命令重新启动：
sudo service httpd restart # For Apache web server sudo service nginx restart # For Nginx web server
对于 Arch Linux，你应该使用类似的东西：
sudo systemctl restart httpd.service sudo systemctl restart nginx.service
这应该允许您的 Web 服务器获取您的新证书更改。
从客户的角度考虑的其他注意事项
由于此错误的广泛性，您还应考虑其他注意事项。 作为 Web 服务和网站的消费者，您还应该迅速做出反应，尽量减少对您的帐户和信息的潜在损害。
您应该考虑之前通过 SSL 保护的任何通信都已受到此错误的影响。 这意味着与安全网站的任何类型的交互都可能被窥探。
一个好的第一步是在您使用的每个站点上更改您的密码， 在 您已验证他们已更新其 OpenSSL 版本以修补此漏洞之后。 如果您在远程站点修补其 SSL 版本之前更改密码，那么您的新密码与旧密码一样容易受到攻击。
一个非常重要的考虑因素是保护您已设置的任何 VPN 实例。 VPN 连接有几种不同的实现方式，但 SSL 是最流行的一种。 例如，OpenVPN 使用 SSL。 应重新生成连接到您的服务器所需的任何证书以确保它们是安全的。
另一个好的措施是删除所有会话密钥和 cookie。 这意味着重新生成 API 密钥、清除浏览器中存储的 cookie 等。 这可能是一个巨大的不便，但现在不经历这些痛苦的代价是您的帐户基本上是开放的，并且与尚未更新其 OpenSSL 的远程服务器的通信应该被认为不比纯文本更安全。
结论
这是一个令人难以置信的大错误，用户和管理员不能忽视或推迟。 您应该立即更新您可以控制的任何服务器，并将漏洞通知您的用户，以便他们可以从头开始进行损害控制。
通过修补您的系统并更新您的 SSL 证书，您应该作为主机免受此漏洞的影响，以便将来进行通信。
