完美的前向保密性可确保 HTTPS 流量保持加密-即使私钥后来遭到破坏

想象一下有人闯入你的房子。从理论上讲，他们可以取代您当时的位置。那真是一个令人恐惧的想法。但是，如果进一步走下去怎么办？如果他们还可以从您过去的房屋中挑选一切，该怎么办？然后还能偷走您将来购买的任何物品吗？听起来像一场噩梦，不是吗？

不幸的是，您的数据可能会发生同样的事情。加密可以确保安全，但前提是您的私钥是安全的。我们所有人都担心我们的一个私钥被泄露，最终落入黑客之手。您未来的通讯将立即受到威胁。不仅如此，是什么阻止他们检查您过去的数据，以获取他们可以利用的多汁，敏感的信息以获取自己的利益？

但请放心，这不是所有的厄运和忧郁。密码学家再次来救援！创建了一个解决方案来解决此类问题，它被称为“完美的前向保密性”。长话短说，它可以防止将来的安全事件损害过去的加密数据。

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

更好的是，它是一项安全功能，并将继续变得越来越普遍。所有主要的浏览器都支持它，Windows XP 之后的操作系统也是如此。SSL 实验室在 2020年10月的扫描中发现，有 21.8％的被调查网站支持所有现代浏览器的完全正向保密，而 64.5％的网站支持大多数浏览器的完美正向保密。只有 1.2％的网站根本不支持完美的前向保密性。   

这个数字还在上升，而且行业巨头的支持当然也没有受到损害。谷歌多年来一直在 Gmail 和其他产品上使用它，而苹果在 2017年对 App Store 提出了完全保密的要求。引入 TLS 1.3 时，Internet 工程任务组（IETF）强制要求完善的前向保密性，仅允许提供密码的西服。这是密码学未来的重要组成部分，这是有充分理由的。

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

让我们将其散列出来。

需要完善的前向保密性

如果不使用完美的前向保密性，那么如果私钥遭到破坏，后果将更加严重。突然，攻击者可以立即访问使用特定密钥在客户端和服务器之间传输的所有过去数据。假设，他们可以记录加密的流量，只要他们愿意，只要等到能够使用私钥即可。然后，一旦拥有了它们，便可以返回并解密自己记录的所有内容。  

假设您使用 HTTPS 登录在线银行，以保护通过互联网发送的密码。明年，在系统管理员意外将私钥上传到 GitHub 后，黑客设法获得了您银行的 TLS 私钥。黑客可以使用该私钥解密去年的会话数据并获取密码吗？没有前瞻性保密，答案是肯定的。

当由于客户端和服务器之间的密钥交换的本质而导致不存在完美的前向保密性时，黑客可以执行此操作。首先，客户端创建一个主密码，该密码用服务器的公钥加密。然后，将其发送到服务器，并在其中使用其私钥解密。现在，客户端和服务器都有主密码。

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

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

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

具有完美前向保密性的威胁预防

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

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

使用 Heartbleed，攻击者告诉服务器，他们将向服务器发送 64KB 心跳请求消息，但发送的消息却小得多。服务器将以最初发送给它的短消息进行答复，但是由于服务器认为应该以更长的消息进行答复，因此它将在消息的其余部分填充碰巧存储在其内的任何数据。攻击可能会一遍又一遍地运行以收集大量数据，这些数据实际上可能包含任何内容–密码，个人数据，会话数据，甚至服务器的私钥。

由于心跳请求是例行事件，因此它永远不会被记录，因此您无法返回查看实际发送的数据。在这里看到问题了吗？如果实际上破坏了服务器的私钥，则黑客可以拦截和解密流量，并且没人会知道。但是，有了完美的前向保密性，就不可能实现整个情况。

后量子世界中的保护

量子计算机的扩散是不可避免的，而且实际上将它们普及给广大公众只是时间问题。当这一天到来时，它将使许多密码算法失效，从而暴露出最初被认为是安全的数据。那么，如何阻止黑客立即收集加密数据，以保存它们，直到他们可以使用量子计算机并对其进行破解为止？

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

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

但是，如果没有完美的前向保密性和对称加密，您的数据将很容易受到收获和解密攻击。例如，让我们看一下标准的 SSL / TLS 握手。如果您可以破坏非对称的私有私钥，则可以使用它来解密握手。然后，您将拥有确定会话密钥所需的条件。

完善的前向保密如何提供帮助 

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

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

实际上，每次重新加载加密页面时，您访问的网站都可能会切换会话密钥。您的电话应用程序可能会在每次通话后切换键。在对话中发送的每条消息之后，您的消息传递应用程序可能会切换键。结果，一个密钥的盗窃不会损害任何其他东西-敏感信息或其他密钥。

SSL / TLS 中的完美转发保密

如您所知，部分 SSL / TLS 握手涉及服务器和客户端就加密套件使用的密码套件达成一致。为了实现完美的前向保密性，必须使用兼容的加密类型。当前，两种密钥交换算法将起作用：

• 短暂 Diffie-Hellman（DHE）
• 暂时椭圆曲线 Diffie-Hellman（ECDHE）

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

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

实施完美前向保密之前需要了解的事情

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

• 需要更多处理能力。这是由于必须为每个新事务生成唯一的会话密钥。在我们讨论的两种密钥交换算法中，ECDHE 是两者中较快的一种，但仍导致处理需求增加了大约 20％。这可能会导致性能下降，从而影响您的客户。
• 缺乏传统支持。尽管几乎所有当前的浏览器和操作系统都支持完美的前向保密性，但较旧的服务器和操作系统却不支持。如果您仍在组织中的某处使用较旧的硬件，则要记住这一点。
• 没有内部数据可见性。凭借完美的前向保密性，您自己的内部团队将对您的加密网络通信无视。例如，如果您遇到服务器问题，那么与其他情况相比，它可以使诊断和修复问题面临更大的挑战。但是，有一些解决方案，例如在服务器上安装 SSL / TLS 检查设备。

在服务器上实施完美的前向保密性   

在服务器上启用完善的前向保密支持的过程非常简单，大多数现代服务器已经为此配置了此过程。如果没有，通常可以通过四个简单的步骤进行操作：

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

我们将很快介绍 Nginx 和 Apache 服务器的特定配置过程。

虽然很容易实现完美的前向保密性，但也很容易错误地配置它。在此过程中，请记住以下一些重要事项：

• 自 SSLv3 起已提供兼容的密码，但我们建议确保您支持最新的 TLSv1.3 协议（正如我们所介绍的那样，该协议要求完全正向保密）
• 您不仅必须选择正确的密码套件，而且还必须确保正确订购了它们：
  • 您还需要短暂的 Diffie-Hellman 密钥交换（因为它会为每个新会话生成不同的会话密钥）
  • 确保包括椭圆曲线 DHE 套件并确定其优先级，因为它们比常规 DHE 更快
  • Logjam 攻击于 2015年被发现，针对的是具有弱 DH 组和 DHE_EXPORT 密码套件的 DHE。因此，建议您禁用 DHE-EXPORT 密码套件，而改用自定义 DH 组。然后，调整定制组中 DH 密钥的大小，以匹配当前的标准长期密钥大小（在撰写本文时为 2048 位）。
    • 如果您的服务器没有用于自定义 DH 组的选项或调整 DH 密钥大小的方法，则只需完全禁用 DHE 密码套件并使用 ECDHE。
  • 一个常见的错误是包括适当的密码套件，但是却忘记了强制执行它们的顺序。启用对 DHE / ECDHE 的支持还不足以实现完美的前向保密性，服务器必须为它们提供优先级。要强制实现完美的前向保密性，只需禁用其他类型的密码即可（例如，FREAK 攻击也于 2015年被发现，是一种利用这种漏洞迫使服务器使用较低优先级和较弱的密码套件之一）。
• 在用户结束会话后，禁用可能保留数据的较长时间的会话 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 上配置完美转发保密

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 上配置完善的前向保密性

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

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

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

SSL 协议全部-SSLv2 -SSLv3

SSLHonorCipherOrder 在

3.设置正确的 SSL 密码。在这里，我们将在上面的 Nginx 说明中使用相同的示例，以在现代服务器上提供高安全性：

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

4.重新启动服务器：

apachectl -k 重新启动

设置完善的前向保密性以保护您的数据向前移动

随着 TLS 协议的发展，完善的前向保密性的概念日益重要。随着这种发展，越来越多的 Web 浏览器，操作系统，通信软件以及全球行业巨头开始采用它。结果，越来越多的网站所有者现在可以使用它来进一步提高安全性并保护其数据。

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

无论哪种方式，该行业都朝着完美的前向保密性方向发展，并且将来不可避免地会成为要求。是否立即进行切换还是等待直到绝对必要，取决于您自己。但是，如果您处理敏感信息或受数据法规的约束，那么尽早采用完善的前向保密性就是个好主意。