我最近读到了 HTTPS 的工作原理，我有一些问题需要澄清。如果这听起来很愚蠢，请原谅我，但我只需要弄清楚这一点。如果我错了，请纠正我。
我知道，作为 TLS 握手开始的一部分，有一个非对称加密，其中证书中的公钥用于在客户端生成的密钥发送到服务器之前对其进行加密，并且只有服务器可以使用其私钥对其进行解密。
但是后续消息（HTTP 请求）使用客户端生成的密钥进行对称加密，客户端和服务器都使用此密钥来加密和解密应用程序数据。
密码学中有一个著名的理论，即“重复不好”，如果一条消息在加密消息中重复，则很容易破解它。如果这是真的，所有使用客户端生成的密钥加密的消息都将包含HTTP/1.x在其中，因为它是 HTTP 请求和响应的一部分。
因此，理论上，拥有这些知识的中间人可能会在加密的 HTTP 请求和响应中找到模式，并找出其中的HTTP/1.x字符串，然后蛮力生成用于加密这些消息的客户端密钥。
我是正确的还是这完全没有意义，任何答案或指导将不胜感激。
首先，有几点。
在任何不提供信息论完美保密的密码系统中，密钥总是可以被暴力破解。确定密码是否安全的关键组成部分之一是暴力破解密钥是否可行，如果可行，则密码不安全。因此，暴力破解密钥不是问题。
泄露的明文信息不一定会危及密钥。它肯定会损害安全性，但知道两条消息的密文并不意味着您了解有关密钥的任何信息。所以，虽然暴力破解密钥仍然是可能的，但这并没有给你任何优势。仍然很难确定正确的密钥，就好像没有重复的密文一样。
在 ECB（电子密码本）模式下使用分组密码可以找到该缺陷的典型示例。在这种模式下，每个明文块都直接使用密钥加密，因此如果存在多个包含相同数据的明文块，它们将产生相同的密文块。很容易看出它们是重复的，这正是您所关心的。
我们解决这个问题的方法（以及也在 TLS (HTTPS) 分组密码中实现的机制）是添加一个额外的随机组件，称为初始化向量。这是一个引入加密过程的非秘密随机值，对于每条加密消息都不同。因为现在每条消息的密钥和 IV 都是唯一的，所以密文也将是唯一的，即使在两条相同消息的情况下也是如此。只要您从不重复使用具有相同密钥的 IV，就不会检测到任何模式，并且攻击者将永远无法确定两条消息是相同的。
非对称密码术建立了一个共享秘密，在TLS 术语中称为主秘密。主密钥在整个会话期间是固定的；一个 TLS 会话包含一个或多个连接（在重用主密钥的同时打开一个新连接称为会话恢复并使用“缩写握手”）。
对于每个连接，从主密钥派生几个密钥（通过一种称为PRF的散列函数）；这些密钥包括用于处理双向流量的加密密钥和 MAC 密钥。推导使用主密钥和“客户端随机”和“服务器随机”作为输入；这些“随机数”是客户端和服务器在握手开始时（在ClientHello和ServerHello消息中）相互发送的值。因此，即使重复使用主密钥，每个新连接也将拥有自己的一组加密密钥。
在每个连接中，数据作为单独的数据包发送，称为记录。给定方向（客户端到服务器，或服务器到客户端）上的所有记录都将使用相同的密钥进行加密；但是，加密机制使用每个记录的状态（隐式或显式初始化向量- 取决于协议版本 - 在使用 CBC 或 GCM 加密的情况下；RC4 加密的运行状态）确保即使两个连续的记录包含完全相同的明文数据，加密版本将是不同的，窃听者将无法检测到该重复。此外，每条记录中添加的MAC是根据明文数据和 记录序列号，以便可靠地检测到任何复制、删除或重新排序记录的尝试。
至于蛮力，它不会受到任何重复的明显影响。事实上，对于任何暴力攻击分析，我们已经假设攻击者知道大量的明文数据和相应的密文。对称密钥大小使得即使在这些条件下，暴力破解仍然是不可行的（有太多可能的 128 位密钥，无论有多少明文/密文对可用，找到正确密钥的机会都非常低）。