行业新闻与博客

完美的前向保密确保 HTTPS 流量保持加密——即使私钥后来被泄露

想象一下有人闯入你的房子。理论上，他们可以拿走你当时位置上的任何东西。这是一个足够可怕的想法。但如果它更进一步呢？如果他们也可以从你家里过去的所有东西中挑选出来怎么办？然后还能偷走你未来购买的任何物品吗？听起来像一场噩梦，不是吗？

不幸的是，您的数据也会发生同样的事情。加密可以保证它的安全，但前提是您的私钥是安全的。我们都害怕我们的私钥之一被泄露，最终落入黑客手中。您未来的通信将立即处于危险之中。不仅如此，还有什么阻止他们检查您过去的数据以获取他们可以为自己谋取利益的多汁、敏感信息？

但别担心，这并不全是厄运和沮丧。密码学家再次前来救援！创建了一个解决方案来处理这类问题，它被称为“完美前向保密”。长话短说，它可以防止未来的安全事件破坏过去的加密数据。

越来越多的网站所有者正在利用完美的前向保密

更好的是，它是一种越来越普遍的安全功能。所有主流浏览器都支持它，后 Windows XP 操作系统也是如此。SSL Labs 在 2020 年 10 月的扫描中发现，21.8% 的受调查站点支持所有现代浏览器的完全前向保密，64.5% 的站点支持大多数浏览器的完全前向保密。只有 1.2% 的网站根本不支持完全前向保密。   

数字不断上升，行业巨头的支持当然也没有受到伤害。谷歌多年来一直将其与 Gmail 和其他产品一起使用，苹果公司在 2017 年将完全前向保密作为 App Store 的一项要求。引入 TLS 1.3 时，互联网工程任务组 (IETF) 要求完全前向保密，只允许提供它的密码套装。这是密码学未来的重要组成部分，并且有充分的理由。

那么完美前向保密究竟是如何工作的呢？为什么它具有如此强大的安全功能？您如何在自己的服务器上启用它？

让我们讨论一下。

完美前向保密的必要性

如果不使用完全前向保密，如果私钥被泄露，后果会更加严重。突然间，攻击者可以使用特定密钥立即访问客户端和服务器之间传输的所有过去数据。假设他们可以根据需要记录加密流量，直到他们能够拿到私钥为止。然后，一旦他们拥有它，他们就可以返回并解密他们一直在记录的所有内容。  

假设您使用 HTTPS 登录网上银行以保护您的密码，因为它是通过 Internet 发送的。明年，在系统管理员不小心将私钥上传到 GitHub 后，一名黑客设法拿到了您银行的 TLS 私钥。黑客能否使用该私钥解密您去年的会话数据并获取您的密码？如果没有前向保密，答案是肯定的。

由于客户端和服务器之间密钥交换的性质，当完全前向保密不存在时，黑客可以这样做。首先，客户端创建一个预主密钥，用服务器的公钥加密。然后，它被发送到服务器，在那里用它的私钥解密。现在，客户端和服务器都拥有预主密钥。

从这一点开始，会话密钥基于预主密钥生成，并用于来回通信。这些会话密钥称为主密钥。但是，如果服务器在 pre-master 加密过程中重复使用相同的私钥怎么办？然后，如果攻击者能够窃取该密钥，他们就能够窃听和解密服务器的所有加密通信，包括过去的数据。

为了使这种情况发生，攻击者将监视流量以获取加密过程中使用的两个随机数（一个由客户端使用，一个由服务器使用）。它们以纯文本形式传输，因此并不困难。他们还可以获得加密的预主密钥。由于他们现在有了服务器的私钥，他们可以用它解密预主密钥。此时，他们拥有生成主密钥所需的所有拼图，从而解密所有会话数据。

一个特定的会话可能不包含任何敏感数据，但如果黑客观察的时间足够长，那么他们很有可能最终能够找到值得一试的东西。

完美前向保密的威胁预防

Heartbleed 证明了为什么需要完美的前向保密

您可能还记得听说过 Heartbleed 漏洞。这是 2012 年发现并最终在 2014 年修复的 OpenSSL 漏洞。黑客利用称为“心跳请求”的服务器操作，通常用于确定服务器是否仍然在线。

通过 Heartbleed，攻击者告诉服务器他们将向服务器发送一个 64KB 的心跳请求消息，但实际上他们发送了一个小得多的消息。服务器会用最初发送给它的短消息进行回复，但由于服务器认为它应该用更长的消息进行回复，因此它会用内存中恰好有的任何数据填充消息的其余部分。攻击可以反复运行以收集大量数据，这些数据实际上可能包含任何内容——密码、个人数据、会话数据，甚至服务器的私钥。

由于心跳请求是一个例行事件，它永远不会被记录下来，所以您无法返回查看实际发送了哪些数据。看到这里的问题了吗？如果服务器的私钥实际上被泄露，黑客就可以拦截和解密流量，而没有人会知道。然而，有了完美的前向保密，这整个场景就不会发生。

后量子世界中的保护

量子计算机的普及是不可避免的，它们被大众普遍使用只是时间问题。当那一天到来时，许多加密算法将变得无用，暴露原本被认为是安全的数据。那么，如何阻止黑客现在收集加密数据以保存数据，直到他们拿到量子计算机并破解它？

答案是什么。事实上，许多网络犯罪分子目前都在进行这种类型的攻击，通常称为“收获和解密”。具体来说，他们目前正在执行攻击的“收获”部分，而“解密”部分必须等待量子计算。等待几年是一个很小的代价，但是，如果最终结果是解密国家机密、财务记录或机密知识产权等高价值信息。

那么完美前向保密在哪里发挥作用呢？由于使用了对称加密方法，它可以保护您的数据。量子计算机无法破解它，因为它不会拥有所需的所有拼图。会话密钥不会通过网络交换，而是由双方根据复杂的方程式独立生成。您可以在此处阅读有关非对称和对称加密以及它们如何协同工作的更多信息。

然而，如果没有完美的前向保密和对称加密，您的数据很容易受到收集和解密攻击。例如，让我们看一下标准的 SSL/TLS 握手。如果你能破解私有的、非对称的私钥，那么你就可以用它来解密握手。然后你就有了确定会话密钥所需的东西。

完美前向保密如何提供帮助 

完美前向保密是 SSL/TLS 的一项功能，可防止攻击者在能够窃取特定会话中使用的私钥的情况下解密历史或未来会话中的数据。这是通过使用经常自动生成的唯一会话密钥来实现的。会话密钥也不会直接来回发送，因为它们是使用不依赖于任何已知先验知识的方法（Diffie-Hellman 密钥交换协议）创建的。因此，攻击者无法通过解密握手过程中发送的数据来获取会话密钥。 

通过使用唯一的会话密钥，攻击者只能查看特定于特定交易所的数据。风险敞口因此大大降低。黑客将不太可能以使用完全前向保密的服务器为目标，因为他们的努力将导致访问相对少量的数据。由于不断生成新参数，因此攻击者也没有未来的收益。

实际上，您正在访问的网站可能会在每次重新加载加密页面时切换会话密钥。您的电话呼叫应用程序可能会在每次通话后切换按键。您的消息传递应用程序可能会在对话中发送每条消息后切换按键。因此，窃取一把钥匙不会危及其他任何东西——敏感信息和其他钥匙都不会。

SSL/TLS 中的完美前向保密

您可能知道，部分 SSL/TLS 握手涉及服务器和客户端就用于加密通信的密码套件达成一致。为了实现完美的前向保密，必须使用兼容类型的加密。目前，有两种密钥交换算法可以工作：

• 短暂的迪菲-赫尔曼 (DHE)
• 短暂椭圆曲线 Diffie-Hellman (ECDHE)

其中一个密钥（没有双关语意）是交换必须是短暂的，这意味着会话密钥只能一次性使用。并且由于它们基于交换中每一方提供的随机值，因此每个新密钥都是唯一的。每次使用后，所有与交易相关的加密信息都会被删除，并生成新的 Diffie-Hellman 参数。这就是将受损会话密钥的使用限制在一个特定会话中的原因。

另一个密钥是 Diffie Hellman 密钥交换协议本身。由于 Diffie-Hellman 背后复杂的数学运算，无法通过暴力获取会话密钥。这是因为，正如我们前面提到的，它实际上并不是在任何时候发送的，而是通过独立的数学方法生成的。它使服务器的私钥对攻击者毫无用处，因为相应的公钥从未用于加密任何内容。

实施完美前向保密之前要知道的事情

在您的网站上部署完全前向保密之前，您应该了解以下几点：

• 需要更多的处理能力。这是因为必须为每个新交易生成一个唯一的会话密钥。在我们讨论的两种密钥交换算法中，ECDHE 是两者中较快的一种，但仍然导致处理要求增加大约 20%。这可能会导致速度放缓，从而影响您的客户。
• 缺乏遗留支持。虽然几乎所有当前的浏览器和操作系统都支持完全前向保密，但较旧的服务器和操作系统却不支持。如果您仍在组织中的某个地方使用旧硬件，请记住这一点。
• 没有数据的内部可见性。通过完美的前向保密，您自己的内部团队将对您的加密网络通信视而不见。例如，如果您遇到服务器问题，那么诊断和修复这些问题会比其他情况下面临更大的挑战。然而，有一些解决方案，比如在服务器上安装 SSL/TLS 检查设备。
• 您的服务器已经在使用什么密码。您可以检查您的浏览器以查看您的 HTTPS 连接正在使用哪种密码。这是 GSX 的一篇热门文章，它引导您完成识别 Chrome 和 Firefox 中的 HTTPS 连接正在使用哪种密码的步骤。

在您的服务器上实现完美的前向保密   

在您的服务器上启用完美前向保密支持的这个过程非常简单，大多数现代服务器都已经配置好了。如果没有，您通常可以通过四个简单的步骤来完成：

1. 进入 SSL 协议配置
2. 添加 SSL 协议
3. 设置与完美前向保密兼容的 SSL 密码
4. 重新启动服务器

稍后我们将介绍 Nginx 和 Apache 服务器的具体配置过程。

虽然完全前向保密很容易启用，但也很容易错误地配置它。以下是您在整个过程中要记住的一些重要事项：

• 兼容的密码自 SSLv3 以来已经可用，但我们建议确保您支持最新的 TLSv1.3 协议（正如我们所介绍的，它要求完全前向保密）
• 您不仅必须选择正确的密码套件，而且必须确保它们的顺序正确：
  • 您还需要一个短暂的 Diffie-Hellman 密钥交换（因为它会为每个新会话生成不同的会话密钥）
  • 确保包括并优先考虑椭圆曲线 DHE 套件，因为它们比常规 DHE 更快
  • 2015 年发现的 Logjam 攻击针对具有弱 DH 组和 DHE_EXPORT 密码套件的 DHE。因此，我们建议您禁用 DHE-EXPORT 密码套件，并改为使用自定义 DH 组。然后，调整自定义组中 DH 密钥的大小以匹配当前标准长期密钥大小（2048 位，截至本文撰写时）。
    • 如果您的服务器没有自定义 DH 组或调整 DH 密钥大小的选项，则只需完全禁用 DHE 密码套件并使用 ECDHE。
  • 一个常见的错误是包含适当的密码套件，但随后忘记强制执行它们的顺序。启用对 DHE/ECDHE 的支持不足以实现完美的前向保密，服务器必须给予它们优先权。要强制完全前向保密，只需禁用其他类型的密码（例如，同样在 2015 年发现的 FREAK 攻击是一种强制服务器使用优先级较低且较弱的密码套件之一的漏洞）。
• 禁用持续时间更长的会话 ID 和可能在用户结束会话后保留数据的票证。有时甚至需要完全重启才能完全清除服务器中的旧会话票证。

完成上述所有步骤后，密码套件列表的顶部应如下所示：

• TLS_EDCHE_RSA_WITH_AES_128_CBC_SHA
• TLS_EDCHE_RSA_WITH_AES_256_CBC_SHA
• TLS_EDCHE_RSA_WITH_3DES_EDE_CBC_SHA

在 Nginx 上配置完全前向保密

注意：这些说明仅适用于特定版本的 Linux。

1. 使用以下命令找到 SSL 协议配置：

grep -r ssl_protocol /etc/nginx

2. 将 SSL 协议添加到您的配置中：

ssl_protocols TLSv1.2 TLSv1.1 TLSv1；

ssl_prefer_server_ciphers 开启；

3. 设置正确的 SSL 密码，并参考我们在上一节中的提示以选择正确的密码。下面的示例在现代服务器上运行良好，并提供了高级别的安全性：

ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

4. 重启你的服务器：

sudo 服务 nginx 重启

在 Apache 上配置完全前向保密

注意：这些说明仅适用于特定版本的 Linux。

1. 使用以下命令找到 SSL 协议配置：

grep -i -r “SSLEngine” /etc/apache

2. 将 SSL 协议添加到您的配置中：

SSLProtocol 所有 -SSLv2 -SSLv3

SSLHonorCipherOrder on

3. 设置正确的 SSL 密码。您可以使用以下命令执行此操作以在现代服务器上提供高安全性：

SSLCipherSuite “EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH”

4. 重启你的服务器：

apachectl -k 重启

以下是一些可能有用的其他资源：

• Apache.org 的文章 SSL/TLS Strong Encryption: How To
• Qualys 的文章 Configuring Apache, Nginx, and OpenSSL for Forward Secrecy

设置完美的前向保密以保护您的数据向前发展

随着 TLS 协议的发展，完美前向保密的概念变得越来越重要。随着这种演变，全世界的网络浏览器、操作系统、通信软件和行业巨头越来越多地采用它。因此，越来越多的网站所有者现在可以使用它来进一步提高安全性并保护他们的数据。

如果您使用的旧系统没有完美的前向保密性，您应该强烈考虑升级。这将需要一些时间和精力，但最终为所提供的好处付出的代价很小。对于攻击者来说，您将成为一个不太有吸引力的目标，因为即使成功的攻击也不会给他们带来太多好处（如果有的话）。

无论哪种方式，该行业都在朝着完全前向保密的方向发展，这将是未来不可避免的要求。是现在进行切换还是等到绝对必要时再进行切换取决于您。但是，如果您处理敏感信息或受数据监管法律的约束，那么尽快采用完全前向保密是个好主意。