TLS 如何工作（RSA、Diffie-Hellman、PFS）？

信息安全 tls diffie-hellman 完全前向保密
2021-08-29 00:06:44

我知道“TLS 的工作原理”已经在这里和crypto讨论过很多次，但我仍然有些困惑，并想在这个巨大的文本中总结我迄今为止所知道的1 ，希望有一天这会有所帮助。

有两种流行的 TLS 密钥交换方法：RSA和DH. 无论哪种情况，典型的 TLS 握手如下所示：

  1. 客户端发送一条ClientHello消息，其中包含它支持的最大 TLS 版本和按偏好顺序排列的密码套件列表。此外，ClientHello.random还传输了一个随机的 28 字节值调用。

  2. 服务器回复一条ServerHello消息，其中包含它可以支持的最佳密码套件和版本，以及它自己的随机 28 字节值ServerHello.random和一个数字证书。

  3. 客户端根据其受信任的 CA 存储验证服务器的数字证书。然后客户端创建一个pre_master_secret，使用从服务器数字证书中提取的服务器公钥对其进行加密，并将其发送回服务器。这被称为ClientKeyExchange.

  4. 服务器使用其私钥解密消息，然后生成主密钥。

在 TLS 1.2 中生成的方式master_secret如下2：

  master_secret = PRF(pre_master_secret, "master secret",
                      ClientHello.random + ServerHello.random)
                      [0..47];

  1. 之后，客户端还向ChangeCipherSpec服务器发送记录（6 字节），表明它想使用对称加密以及Finished消息。

  2. 服务器回复消息ChangeCipherSpec以及Finished消息。

  3. 从此时起，所有流量都将通过 TLS 进行通信并进行加密。

问题1："master secret"推导中的内容是什么？换句话说，实际价值是多少？

问题2：客户端如何加密它的消息？使用什么密钥/秘密？我不确定角色的作用master_secret？

问题 3：在3（RFC 第 7.3 节）中，它说以下内容，这些“随机值”是什么？它们的目的是什么？

  • 从预主密钥生成主密钥并交换随机值。

问题 4：我经常阅读术语“会话密钥”。它是什么？是master_secret吗？

RSA

我知道 RSA 可以在上面的步骤 3 中用于完整性控制，这意味着使用公钥-私钥非对称加密，因此pre_master_secret在明文中不可读。

DH使用RSA 的主要弱点是使用服务器私钥。如果服务器的私钥被泄露，攻击者可以记录所有流量并解密流量。因此，为了提供前向保密4，可以使用 DH。

DH 的工作原理是离散算法。数学特性允许双方（客户端和服务器）生成自己的秘密（分别为 a，b），并推导出相同的shared secret给定 p、G 和 g^X mod p（其中 x 分别为 a 和 b）公共频道（全世界都可以阅读）5．

问题 4： 我相信所有后续流量都将使用共享密钥进行加密，对吗？

完美前向保密 (PFS)

为了确保没有人可以读取之前记录的流量，引入了 PFS。基本上，客户端和服务器不使用长期共享密钥，而是生成从内存中丢弃的短期会话密钥。

问题 5： 什么是短命密钥？客户端和服务器的 X（分别为 a 和 b）？

PSF 和 RSA

我的理解是 RSA 用于身份验证（“服务器”发送的内容来自“服务器”，而不是 MiTM）。有用于完整性检查的 HMAC，它是在密钥交换期间生成的。

问题6： 对吗？

我可能会省略其他相关问题/细节。但任何回应表示赞赏。

1个回答

坦率地说，我不认为这会非常有用。是因为它可能 ....

作为初步问题，您所说的几乎所有内容都仅适用于 TLS 1.2 版。TLS 1.3 版对协议进行了相当大的更改，于去年发布（经过长时间的延迟），现在正在传播中；根据历史经验，TLS<=1.2 很可能会在 3 年内消失。公平地说，您可以在网上轻松找到大部分资源，尤其是 1.3 之前的 #20803 的 Ursine Epics。

无论哪种情况，典型的 TLS 握手如下所示：

两者都不是，您所描述的仅涵盖RSA；DH不一样。更多内容如下。

  1. ...此外，还有一个名为 ClientHello.random ... 的随机 28 字节值。
  2. ... ServerHello 消息 ... 以及它自己的称为 ServerHello.random 的随机 28 字节值和数字证书。

命名的字段.random实际上是 32 个字节，分为 4 个字节的时间戳（如果您的计算机时钟甚至模糊正确，这不是随机的，因为它应该是）和 28 个字节的实际随机数据。密钥派生等中使用的值是 32 字节值。

严格来说，服务器证书不在ServerHello消息中，而是在单独的消息中。然而，这两个消息，加上适用时的 ServerKeyExchange 和 ServerHelloDone 总是可以成为一条记录的一部分，并且通常是一个 TCP 级别传输的一部分。更实质的是，如果服务器证书需要验证一个或多个中间证书或“链”证书（如今几乎总是如此），则也应包括（那些）链证书；几个堆栈上有很多关于“浏览器认为我的服务器连接安全但 $other_sw 给出 $some_error”的问题，这通常是由于未正确配置链证书。（A 通常因所涉及的服务器软件而异。）

  1. 客户端根据其受信任的 CA 存储验证服务器的数字证书。然后客户端创建一个pre_master_secret，使用从服务器数字证书中提取的服务器公钥对其进行加密，并将其发送回服务器。这被称为ClientKeyExchange
  2. 服务器使用其私钥解密 [premaster]，然后生成主密钥

客户端验证服务器证书，（通常）通过其链，针对客户端的信任库，并验证服务器证书与客户端想要连接的服务器的名称（或可能的地址）匹配。（如果我们想连接到 HonestBank.com，并尝试连接让我们获得由受信任的 CA 颁发给 WeAreCrooks.com 的证书，我们不想在该连接上发送我们的银行信息。）

服务器和客户端都从 premaster 和 2 个 random 派生 master_secret。

如果服务器请求客户端身份验证，也称为客户端证书或“双向”或“相互”身份验证，则客户端实际上在 ClientKeyExchange 之前发送 Certificate，在之后发送 CertVerify。这在 5246 中都有解释，但很少使用。

  1. 之后，客户端还向服务器发送 ChangeCipherSpec 记录（6 字节），表示它要使用对称加密......
  2. 从此时起，所有流量都将通过 TLS 进行通信并进行加密。

在 CCS 之后，所有流量都经过加密和身份验证；两者都很重要。方法各不相同：较旧的密码套件使用（纯）密码进行加密，使用（单独的）HMAC 进行身份验证（HMAC = Hash-based Message Authentication Code）；1.2 还具有新的（2008 年）经过身份验证的密码，正式称为 AEAD = Authenticated Encryption with Additional Data，它在一个组合操作中同时进行加密和身份验证；将第 6.2.3.3 节与前几节进行比较。

问题一：推导中的“主秘”是什么？换句话说，实际价值是多少？

每个会话都不同，除了两个端点（客户端和服务器）之外没有人应该知道它，因此是“秘密”。（尽管有时调试功能可以让您提取它；它们有几个 Q。）它的值是使用您从 8.1 发布的公式计算的。如果您的浏览器上的“搜索”功能被破坏并且您的显示中的某些缺陷使目录不可见，PRF 是 Pseudo(R)andom Function 的缩写，并在第 5 节中进行了解释。

问题2：客户端如何加密它的消息？使用什么密钥/秘密？我不确定master_secret的作用？

master_secret 用于派生多个工作密钥，或者更准确地说是秘密；见第 6.3 节。客户端使用“client_write_key”进行加密，服务器使用它进行解密。对于使用 IV 的密码套件，在 1.2 中只有一些 AEAD，它们也使用client_write_IV. 对于使用 HMAC 的密码套件，即非 AEAD 密码套件，客户端使用它client_write_MAC来生成 HMAC，服务器使用它来验证。请参阅会话密钥是否只是对称密钥？或交叉https://crypto.stackexchange.com/questions/1139/what-is-the-purpose-of-four-different-secrets-shared-by-client-and-server-in-ssl。

问题 3：在 3（RFC 第 7.3 节）中，它说如下，那些“随机值”是什么，它们的目的是什么？

  • 从预主密钥生成主密钥并交换随机值。

这正是您在第 8.1 节的 3 中发布的公式。发送到服务器的 ClientHello.random 和发送到客户端的 ServerHello.random 是交换随机值，并与（共享的）premaster_secret 组合生成（也是共享的）主密钥。

问题 4：我经常阅读术语“会话密钥”。它是什么？是master_secret吗？

它可以是 master_secret 或派生的工作密钥/秘密（复数），或两者兼而有之。特别是，TLS<=1.2 中的会话恢复（也称为重用）是通过保存会话 ID（在 ServerHello 中）和相应的安全参数（包括主密钥）来完成的，然后在后续甚至并发连接上使用它们.

RSA

我知道 RSA 可以在上面的步骤 3 中用于完整性控制，这意味着使用公钥-私钥非对称加密，因此 pre_master_secret 在明文中不可读。

“普通” RSA 密钥交换确实使用 RSA 加密，这是一种非对称加密，也就是公钥加密，因此 pre_master_secret 不可读。尽管非对称或公钥加密确实使用公钥和私钥，但我们通常不会说“公钥-私钥”。我不知道您所说的“完整性控制”是什么意思；RSA 加密并不能很好地抵抗对手操纵密文，这使得Bleichenbacher的攻击仍然是一个问题。对普通 RSA 握手的（唯一）保护是 Finished 消息中的 PRF 值，它充当一种 MAC（只要至少一个端点是诚实和正确的）。

DH 使用 RSA 的主要弱点是使用服务器私钥。如果服务器的私钥被泄露，攻击者可以记录所有流量并解密流量。因此，为了提供前向保密 4，可以使用 DH。
DH 的工作原理是离散算法。数学特性允许双方（客户端和服务器）生成自己的秘密（分别为 a、b），并在给定 p、G 和 g^X mod p（其中 x 分别为 a 和 b ）通过公共渠道（全世界都可以阅读） 5.

那是离散对数。更准确地说，Diffie-Hellman ephemeral提供前向保密；关键是“短暂的”。1.2（及更早版本）还定义了静态（非临时）DH 密钥交换，但这些实际上从未使用过，主要用于引起混淆。（它们在 1.3 中被完全删除。）技术上有两种变体：使用整数的原始 DH-ephmeral，在 TLS 中指定为 DHE；以及椭圆曲线版本，指定为 ECDHE。尽管相同的原则适用于两者，但实现它们的实际代码（和数据）却大不相同。

问题4：我相信所有后续流量都会使用共享密钥加密，正确

不是直接的。[EC]DHE 协议生成的秘密用作 premaster-secret，以与上述相同的方式：首先派生为主机密，然后派生到工作密钥/机密。在您发布的摘录之后立即比较第 8.1.1 节和第 8.1.2 节。

完美前向保密 (PFS)
为确保没有人可以读取先前记录的流量，引入了 PFS。基本上，客户端和服务器不使用长期共享密钥，而是生成从内存中丢弃的短期会话密钥。
问题 5：什么是短命密钥？客户端和服务器的 X（分别为 a 和 b）？

是的。除了虽然通用 DH 通常用 a/A 和 b/B（规范地，Alice 和 Bob）来描述，TLS 规范使用不同的符号。对于 5246 中的 integer-DHE，服务器和客户端的公钥分别是dh_Ys和dh_Yc; （已更正！）相应的私钥大概是 Xs 和 Xc，但未显示。对于 4492 中的 ECDHE，服务器公钥被简单命名public，而客户端公钥被命名ecdh_Yc（即使在 ECC 中，我们通常使用 X，Y 作为点的坐标，并调用私钥（整数）d 和公钥（点）Q ) 并且再次没有显示私钥。

PSF 和 RSA
我的理解是 RSA 用于身份验证（“服务器”发送的内容来自“服务器”，而不是 MiTM）。有用于完整性检查的 HMAC，它是在密钥交换期间生成的。
问题6：对吗？

（那是 PFS。或者只是 FS。）我完全不确定你在说什么，所以主要重复我之前所说的话：

  • 对于 RSA keyexchange，premaster 通过 RSA 使用证书中的服务器公钥进行加密，握手的唯一完整性检查是 Finished，它使用 PRF，它基于但不同于 HMAC

  • 对于 [EC]DHE 密钥交换，密钥交换参数使用服务器证书中的公钥进行签名。该密钥和签名可能是 RSA（在任何一种情况下），也可能是 DSA（由于历史原因也称为 DSS）或 ECDSA，具体取决于密钥交换

  • 无论密钥交换如何，取决于密码，HMAC 或 AEAD（但不是两者）用于验证数据流量

其它你可能感兴趣的问题
上一篇如果 Google 帐户登录屏幕被欺骗怎么办 下一篇了解 Whatsapp 帐户黑客（社会工程？）