Https 完美前向保密（PFS）是如何工作的

我在一个信息安全课程上，我在网上偶然发现了这个概念，它引起了我的兴趣。我也看过一些解释这个概念的网站和维基百科，以及一些关于stackoverflow的帖子，但我仍然感到困惑。据我所知，在典型的HTTPS公钥交换中，浏览器和服务器与密钥一起创建会话密钥……如果有人获得了派生会话密钥的私钥，他们可以看到此连接之间发送的所有数据，即使是在过去

我的理解是，使用PFS，“会话密钥”永远不会被发送，即使是以加密的形式。它是保密的，因此即使有人发现了私钥，他们也无法访问过去的加密记录信息。这是正确的吗

---

我还想知道，如果我参加PFS交换呼叫我“a”，与服务器“B”，PFS应该工作的事实是，如果我的密钥被泄露，a和B的对话不会被泄露，因为他们不知道会话密钥。但是，如果我的密钥实际上已被泄露，那么“B”如何认证我为“A”。它如何知道我（A）与另一个使用我的密钥试图访问数据的用户（C）之间的区别。

在非PFS会话中，浏览器决定会话密钥（或者说是从中派生的秘密密钥），并使用RSA加密，RSA公钥从属于服务器的证书中获取。该证书还用于对服务器进行身份验证。然后，服务器使用其私钥（您称之为主密钥）解密会话密钥。 所有到服务器的连接都使用不同的会话密钥，但是如果您拥有主密钥，您可以像服务器那样将它们全部计算出来。 在PFS中，您使用Diffie-Hellman等算法，其中不使用主密钥。在这种连接中，主密钥用于验证算法的参数。在商定参数后，使用这些参数进行密钥交换，并且双方都保密。这些参数不是秘密的，在会话密钥建立后（短暂的），双方使用的秘密将被丢弃。这样，如果发现主密钥，则无法发现会话密钥。但是，如果您获得了密钥，并且证书没有失效，则可以冒充服务器。

---

要了解更多信息，请阅读Diffie Hellman。

我非常喜欢罗伯特·洛夫在《古拉》中给出的答案：

让我们看看在常见的非短暂情况下密钥交换是如何工作的。 我不会用Diffie Hellman来举一个实际的例子，我会 给出一个数学简单的通用示例：

Alice（客户机）想和Bob（服务器）通话

Bob有一个私钥X和一个公钥Y。X是秘密的，Y是公开的

Alice生成一个大的随机整数M

Alice使用Y加密M并将Y（M）发送给Bob

Bob使用X解密Y（M），得到M

Alice和Bob现在都拥有M，并将其用作他们同意用于SSL会话的任何密码的密钥，例如AES

很简单，对吧？当然，问题是，如果有人发现了X，那么每个通信都会被破坏：X让攻击者解密Y（M），产生M。让我们看看这个场景的PFS版本：

Alice（客户机）想和Bob（服务器）通话

Bob生成一组新的公钥和私钥Y'和X'

鲍勃把你寄给爱丽丝

Alice生成一个大的随机整数M

Alice使用Y'加密M，并将Y'（M）发送给Bob

Bob使用X’解密Y’（M），得到M

Alice和Bob现在都拥有M，并将其用作他们同意用于SSL会话的任何密码的密钥，例如AES

（X和Y仍然用于验证身份；我不考虑这一点。）

在第二个示例中，X不用于创建共享秘密，因此即使X被泄露，M也是不可发现的。但你可能会说，你刚刚把问题推到了X。如果X'被知道了怎么办？但我认为这才是天才。假设X'从未被重用和存储，获得X'的唯一方法是对手在通信时能够访问主机的内存。如果你的对手有这样的物理访问权限，那么任何类型的加密都不会对你有任何好处。此外，即使X'以某种方式被破坏，它也只会暴露出这种特殊的通信

那是PFS

---

为每条消息生成一个新的公钥，并仅将真正的永久公钥用于身份验证

其他答案中也提到了这一点，但我只想给出一个更易于大脑分析的上下文版本

使用某人的公钥可以做两件事：

• 验证消息是否由他们编写，即验证消息或验证消息。这是防止冲突的必要措施
• 加密只有他们才能解密的消息

在很多方面，身份验证是更关键的/代价高昂的步骤，因为要知道给定的公钥属于某人，同时避免中间人攻击，需要采取如下步骤：

• 在现实生活中与他们见面并共享公钥（离开家？？）
• 通过视频与他们交谈（深水假货？？）
• 可信签名提供程序（集中化！！！）

然而，生成新密钥相对便宜

因此，一旦您完成了这一成本高昂的初始密钥验证步骤，您现在就可以：

• 要求接收者为您要发送的每封邮件生成一个新的临时公钥
• 接收方将临时公钥发送回您，并由其永久公钥签名。任何东西都不会被永久密钥加密，只会被签名。不需要加密发送的公钥
• 使用永久公钥验证消息签名以避免MITM，然后使用该临时密钥