即使使用 HTTPS，也无需使用 CA。如果您在客户端连接到服务器之前以安全（防篡改）的方式向客户端提供此证书的副本或类似（即指纹），则您可以简单地在服务器上使用自签名证书，以便客户端可以验证它与预期的服务器对话。如果客户端无法验证服务器中间人攻击是可能的。

CA 签名证书（即公钥基础设施 (PKI)）的概念之所以被创建，是因为与所有各方共享一个自签名的叶证书无法扩展。使用 CA，浏览器/操作系统具有信任锚（根证书）列表，并且可以基于从受信任的根证书到叶证书的信任链将信任派生到服务器证书。由于这种机制，只有受信任的根 CA 需要共享，而不是所有可能的服务器证书。

除了预先共享的证书或类似的公共信息（如 SSH 服务器指纹）之外，还可以通过使用双方的共享密钥来建立 MITM 抗性连接。这是受 WPA 保护的家庭 Wifi 的典型案例。

首次使用信任 (TOFU) 可实现对 MITM 的有限保护。在这种情况下，对等方的身份从第一个连接中保存并应用于后续连接，希望攻击者不在第一个连接上，即接收到的身份是预期对等方的真实身份。例如，如果一个人接受 HTTPS 中的自签名证书，就会这样做。

SSH 是 TOFU（首次使用时信任）的一个示例，它不需要 CA（或实际上任何第三方）参与建立信任关系。

大多数预共享密钥（例如，用于 wifi 中的 WPA，或用于 VPN 解决方案）如果使用正确，并且不需要通过 CA（或 PKI）建立信任，并且不需要涉及加密令牌。

还要考虑一下 CA 可以促进 MitM（例如，当 CA 被要求颁发证书而不执行验证身份所需的检查时——由于妥协、法律压力或恶意），并且使用 PKI 确实不一定提供任何针对中间人的保护——它只是确定给定的令牌（密钥）被合理地认为代表了（身份）声明，例如，糟糕的加密选择可能会使所有这些声明/断言无效。

更新：

正如@Steffen Ullrich在下面的评论中指出的那样，TOFU 在第一次连接期间容易受到 MitM 的影响。这可以得到缓解（例如，通过提供一些机制来验证正在呈现的主机密钥）。在第一次连接之后，您要么远离 MitM，要么完全暴露。

我的意思是指出 TOFU 是一种建立信任的不同方法（基本上让用户自己弄清楚），但 Steffen 是绝对正确的，即 TOFU 和 PKI 最初采用完全不同的方法来验证身份，由 TOFU 做出设计决定在第一次连接期间不解决 MitM 的风险 - 因此两种信任模型对防范 MitM 的能力有不同的影响。

由于问题是关于为什么很多 MitM 文献提到 PKI，因此这是部分答案：在更常见的防止 MitM 的方法中，基于 PKI 的解决方案比其他方法（如 TOFU）提供更多的保护。

客户端需要某种方式来验证服务器就是它所说的那个人。

有多种方法可以验证这一点：

1. 信任第三方：HTTPS 使用受信任的 CA。PGP 使用信任网络来尝试将发送者和接收者连接在一起。
2. 首次使用时信任：SSH（默认）在用户第一次连接时会要求用户信任服务器，然后如果服务器发生变化，SSH 会警告用户。这也是浏览器倾向于为自签名证书工作的方式——允许记录“异常”。
3. 通过某种越界机制预先共享服务器的公钥，这是您应该使用 SSH 和自签名证书真正安全的方式。