行业新闻与博客

TLS 1.3 中的完美前向保密有助于防止您发送或接收的加密会话数据在接收服务器的私钥稍后遭到泄露时被解密

当人们考虑加密时，他们会从一般角度考虑它是保护数据机密性的一种方法。虽然这是真的，但事情远不止于此。每次用户连接到您的安全网站时，他们的浏览器和您的服务器都会交换创建安全会话的信息。这称为 SSL/TLS 握手，由双方交换数据以创建可用于加密和解密数据的会话密钥来完成。 

听起来不错，对吧？但是，如果交换密钥相关信息的过程不安全并且服务器的私钥或秘密共享会话密钥遭到泄露怎么办？然后，您将发现事情出错的速度有多快，以及依赖于泄露密钥之一的过去会话数据如何可能被暴露。

本文将探讨完美前向保密，以了解它是什么以及为什么它对互联网上的数据安全至关重要。

什么是完美前向保密？

一般来说，完美前向保密（PFS）是一种“秘密武器”，可以防止您之前通过加密会话发送的所有加密数据被坏人解密，即使您的服务器的私有加密密钥将来受到损害。

如果您感到疑惑，请给我们一点时间解释一下。当您连接到安全网站时，您将通过安全会话进行连接，该会话需要使用加密密钥，如果不安全存储，这些密钥可能会落入坏人之手。完美前向保密是指防止通过安全（加密）连接共享的数据因关键泄露问题而暴露

• 每个会话使用新的私钥，并且
• 不允许存储会话密钥以供将来使用。

从更技术的角度来看，完美前向保密是一组密钥协商协议，旨在确保会话密钥（即在典型网站连接中用于将数据传输到网站服务器的密钥）的安全，即使服务器的私钥也是如此变得受到损害。它通过使会话密钥成为一次性工具来实现这一点，就像医疗服务提供者使用一次皮下注射针头和医用手套然后将其丢弃一样。

要更全面地理解完美前向保密，您至少对加密有基本的了解。因此，让我们绕道快速回顾一下什么是加密，然后回过头来谈谈 PFS 如何在互联网安全中发挥作用。

加密和 PFS 在创建安全加密会话中的作用概述

一般来说，加密是获取明文、可读数据并将其转换为只有拥有特定密钥的人才能读取的内容的过程。加密被认为是双向过程，因为加密数据被设计为使用适当的私钥进行解密：

• 非对称加密。在这种加密方法中，有两个密钥可以分担这些职责——一个用于加密的公钥和一个用于解密的私钥。这种密钥组合用于创建一个安全通道，通过该通道在各方之间共享重要的密钥相关值。该数据用于创建对称加密会话，该会话将用于连接的其余部分，以较少的计算开销交换数据。
• 对称加密。在这种类型的加密连接中，有一个密钥可以加密和解密数据。在本例中，这是双方使用其私钥结合通过 SSL/TLS 握手过程交换的公开共享值生成的安全会话密钥，我们稍后将对此进行解释。

当安全会话密钥被泄露时会发生什么？没什么好东西，我们向你保证。但我们稍后会详细讨论这一点。但首先，让我们以您的网站为例。

当客户连接到您的网站时，他们的浏览器和您的 Web 服务器会进行 TLS 握手。这个过程使他们的客户端能够验证您的服务器的身份、保护数据完整性并创建保护数据机密性的安全会话。（这也是他们能够使用安全 HTTPS 协议并使小挂锁图标出现在浏览器地址栏中的原因。）

但这个过程是什么样的呢？当客户通过 TLS 握手连接到您的网站时：

• 他们的客户端和您的服务器使用非对称加密来交换密码信息和可用于创建对称会话密钥的特殊值。
• 客户端使用您的网络服务器的公钥来加密其值，以便没有人（除了您的服务器）可以读取它。
• 然后，您的服务器使用该数据以及特殊参数来创建秘密会话密钥，使其能够与客户的客户端建立安全会话。此对称加密连接将用于会话的其余部分。

TLS 1.3 强制要求完美前向保密

传统上（直到 TLS 1.2），服务器使用 RSA 或传统的 Diffie-Hellman 密钥交换功能：

• RSA 密钥交换涉及在各方之间共享传输的密钥相关数据。
• Diffie-Hellman 密钥交换涉及双方交换公共值（非敏感数据），并将其与各自的秘密值结合起来生成单个密钥。

这些传统的密钥交换方案涉及使用服务器的密钥来保护它将共享的安全会话密钥值。只要服务器的私钥不被泄露，这就很好。如果该密钥被泄露，那么攻击者可以使用它来解密他们保存的任何使用该密钥相应的公共副本加密的数据。

为了避免在 TLS 1.3 中发生这种情况，互联网工程任务组 (IETF) 强制要求使用临时（即动态且唯一）密钥值作为 SSL/TLS 握手的一部分。这需要使用椭圆曲线 Diffie-Hellman 临时 (ECDHE) 密钥交换，而不是传统的非临时 DH。这样，使用 SSL/TLS 握手创建的每个安全会话都有自己的一组用于创建会话的参数（规则）。

根据 IETF 的说法：

“与 TLS 1.2 相比，TLS 1.3 通过加密更多协商握手来保护数据免遭窃听，从而为数据交换提供了额外的隐私。此增强功能有助于保护参与者的身份并阻止流量分析。TLS 1.3 还默认启用前向保密，这意味着协议中使用的长期机密的泄露不允许对使用这些长期机密时通信的数据进行解密。因此，即使未来的通信受到损害，当前的通信也将保持安全。”

在静态密钥交换中，例如传统的 Diffie-Hellman 密钥交换，这些参数中的一个或两个可以重复使用。但不管地球保护活动人士怎么说，并不是所有东西都应该回收。（至少，在公钥加密方面确实如此）。例如，在 Diffie-Hellman 临时密钥协议（DHE）中，必须更改这些参数才能创建每个新会话，并且无法重复使用。每个会话的值的这种变化可以实现完美的前向保密，这意味着每个会话都独立于其之前和之后的会话。

这给我们带来了下一个相关的话题……

前向保密与完美前向保密——不管你信不信，它们是不一样的

您可能在某个时候遇到过“前向保密”一词。当您查看“完美前向保密”和“前向保密”这两个词并且组织经常同义词地使用这些术语时，很容易认为它们是相同的。（请参阅上面的 IETF 引用以获得此类示例。）

然而，这两个术语实际上有一个重要的区别：

• 前向保密只需使用传统（非临时）Diffie-Hellman 密钥交换即可实现。这需要两方使用相互计算的密钥进行连接，而该密钥从未直接交换过。然而，双方将在未来的会话中使用相同的共享密钥。
• 完美的前向保密是您需要更进一步才能实现的。这将需要使用临时加密密钥，例如通过临时 Diffie-Hellman 密钥协议。这意味着每个新会话都需要一个唯一的密钥，无论是两个新方还是之前已连接的两个方。

让我们使用以下插图来考虑这两个概念：

完美前向保密如何运作

从本质上讲，当您为每个 SSL/TLS 会话使用唯一的加密 / 解密密钥时，就会产生完美的前向保密。实现 PFC 的方法是使用临时 Diffie-Hellman 或椭圆曲线临时 Diffie-Hellman 密钥交换作为 SSL/TLS 握手的一部分。

为什么需要完美的前向保密

就其本身而言，前向保密在一个完美的世界中是很好的——一个每个人、公司和组织都遵守安全密钥管理最佳实践的神奇地方。但由于这是现实世界，而他们通常不会这样做——而且网络犯罪分子总是在寻找方法来获取每个人的私钥，以解密他们从之前截获的会话中保存的数据——那么这意味着服务器的私有密钥密钥可能会被泄露。

这就是 TLS 1.3 中强制要求进行临时 Diffie-Hellman 密钥交换的原因；他们确保每个会话都使用新的 Diffie-Hellman 密钥交换参数。这样，从您的会话中保存加密数据的坏人以后将无法解密它，因为密钥将在使用后被销毁，并且不会存储在服务器上。如果您为每个用户使用相同的会话密钥来保护其后续连接，它可以减轻您可能遭受的潜在损害和数据泄露。

支持完美前向保密的密码套件

现在我们知道什么是完美前向保密、它的作用以及为什么它是必要的，让我们看一下使其成为可能的加密密码套件（即加密算法的组合）。为此，我们将其与 TLS 1.2 密码套件进行比较，以便我们可以看到它们之间的差异。

TLS 1.2 密码套件

根据 NIST 的特别出版物 800-52 修订版 2，TLS 1.2 密码套件是用于密钥交换、加密和消息身份验证的协议和算法的组合。例如，TLS 1.2 密码套件如下所示：

                Protocol_KeyExchangeAlgorithm_WITH_EncryptionAlgorithm_MessageAuthenticationAlgorithm 

TLS 1.2 总共支持 37 个密码套件。然而，支持所有这些并不一定是可取的，因为其中一些不支持 PFS。以下是这些密码套件之一的外观：

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS 1.3 密码套件

现在，让我们将其与 TLS 1.3 密码套件进行比较，后者放弃密钥交换算法并使用以下格式：

                Protocol_AHEADcipherMode_HashCipher

在之前链接的资源中，NIST 建议仅将 TLS 1.3 服务器配置为支持四种密码套件：

1. TLS_AES_128_GCM_SHA256
2. TLS_AES_256_GCM_SHA384
3. TLS_AES_128_CCM_SHA256
4. TLS_AES_128_CCM_8_SHA256

IETF 表示 TLS 1.3 支持第五种密码套件- TLS_CHACHA20_POLY1305_SHA256 - 但该套件并未包含在 NIST 的推荐密码套件列表中。

为了实现完美的前向保密，您需要在服务器上支持 TLS 1.3 密码套件。这是因为，在 TLS 1.3 中，仅为当前会话生成会话密钥。一旦课程结束，钥匙就会像去年的运动鞋一样被丢弃——再也不会被看到或使用。

不过，仍然请确保也支持临时密钥密码套件（那些识别 DHE 或 ECDHE 进行密钥交换功能的密码套件），这样您就不会排斥浏览器仅支持 TLS 1.2 的访问者。

如何实现完美的前向保密

如果您想为网站上的连接启用 PFS，那么您需要：

• 在您的 Web 服务器上启用 TLS 1.3。您可以通过在网站上购买并安装 SSL/TLS 证书并将服务器设置为支持 TLS 1.3 协议来实现此目的。
• 采用椭圆曲线 Diffie Hellman (ECDHE) 或 Diffie-Hellman ephemeral (DHE) 密钥交换。但是，请小心按特定顺序构建服务器支持的密码套件列表。将 ECDHE 密码套件放在列表顶部，然后将 DHE 密码套件排在后面。

作为最后的手段，您仍然可以包含浏览器可能支持的非 DH 密码套件，但请记住，这不会提供完美的前向保密。

关于完美前向保密的最终想法

虽然我们很想说 TLS 1.3 及其规定的完美前向保密是标准，但我们在行业内还没有达到这一点。但好消息是我们正在一点一点地实现这一目标。

Qualys SSL Labs 的数据显示，2023 年 2 月，他们分析的 15 万个启用 SSL/TLS 的网站中，99.9% 支持 TLS 1.2，60.4% 支持 TLS 1.3。现在，将其与他们上个月分析的支持 TLS 1.3 的网站中的 59.8% 进行比较。虽然这个数字不一定是我们希望达到的行业水平，但这仍然是个好消息，因为这意味着我们整体上正朝着正确的方向前进。