要引用您参考的文章中的重要部分：

缺点是这种安全性分别应用于通信路径中的每一跳，使得通信容易受到中间人攻击。

TLS 用于不同的用例。其中一些案例涉及消息的单个端到端传输，例如让客户端将消息发送到 Web 服务器，然后由服务器直接处理。在这种情况下，TLS 成功地防止了中间人攻击。

但是当涉及多个跃点时，也会使用 TLS。在这种情况下，传输仅受这些跃点之间的 TLS 保护，但中间任何一个跃点的人都可以拦截未加密的数据。这个用例是典型的邮件（即 SMTP），但您也可以在使用反向代理、内容交付网络或类似网络时通过 HTTPS 找到它。在这些情况下，TLS 仅提供逐跳安全性，而不提供端到端安全性。后者可以通过在传输之前加密消息并在完成完整传输（即所有跃点）之后对其进行解密来实现。对于邮件，这通常使用 PGP 或 S/MIME 完成。

想象两种不同的场景：

典型/直接呼叫

你有一个客户端和一个服务器。客户端向服务器发送消息；服务器对请求进行处理，创建响应，并清空包含原始请求的内存。该请求不会转发到任何其他系统。

在这种情况下，传输很好，并且不会特别容易受到中间人的影响，假设您已经正确配置了传输层安全性。有很多配置您可以搞砸，但您应该能够使用渗透测试来审核和纠正这些配置。

涉及三方或更多方的通话

您有一个客户端、一个应用程序服务器和一个特定于域的服务器（例如，运行银行主机中间件的服务器）。客户端向应用服务器发送消息；应用服务器解析消息，验证调用者，并将其中的一部分转发给银行主机。

在这种情况下，消息层安全协议将允许银行主机相信从原始客户端收到的请求消息完好无损且不受干扰。如果您使用传输安全，则应用程序服务器可能做了一些恶意的事情，因为它会解密并重新加密消息。借助消息层安全性，您可以对消息的某些部分进行加密或签名，并原封不动地传递。

与受信任的中间人一起使用传输安全性

话虽如此，如果应用程序服务器是可信的，银行主机可以验证应用程序服务器（通过传输安全），如果它使用客户端证书。通过这种设置，您可以使用传输层安全性，同时适当减轻中间人攻击的风险。

声称“传输模式”的安全性是不安全的：

“传输模式是最不安全的选择，应该避免。”

我会说你误读了文件。并不是说运输方式不安全；它说它是最不安全的选项——而且，隐含地，在它所谈论的一组选项中。

您不应将安全视为二元是/否问题；相反，您应该更具体地看待它，作为系统可能受到攻击的方式的列表。在他们的情况下，即使传输安全配置尽可能强（每个客户端和服务器之间的 SSL 证书），也存在通信通过多个 SSL 跃点的情况（例如，客户端之间存在负载平衡代理和端点）。如果该链中的任何服务器被黑客入侵，则攻击者可以破坏两者：

1. 机密性：攻击者能够读取有效载荷的内容。
2. 真实性：攻击者能够伪造看似来自客户端的消息。

另一种说法：如果您在该配置中使用系统，则客户端可能会信任中间服务器而不是伪造消息。它并不比那些中间服务器更安全。

他们提供的另外两个选项是他们所谓的“消息安全”和“消息凭证”。这些选项允许客户端不太信任服务器：

• 在消息安全模式下，客户端使用中间服务器没有的密钥加密每条消息，只有最终端点。因此，如果攻击者闯入中间服务器，他们只能丢弃消息（并且可能无法检测到）。
• 他们没有很好地解释消息凭证模式，以至于我可以很好地理解它的安全性。客户端不加密消息，因此闯入代理的攻击者肯定可以读取它们。与传输安全相比，传输安全的优势似乎在于每个跃点都经过身份验证（客户端使用代理进行身份验证，代理使用端点进行身份验证），但使用消息凭据，客户端向端点进行身份验证。但是，我无法判断闯入代理的攻击者是否能够伪造消息。（糟糕的文档！）

请注意，对于所有三种模式，在某些情况下，攻击者会导致一些不好的事情发生。同样，安全不是是/否的问题。

引用您自己的链接：

当使用像 HTTPS 这样的传输时，这种模式的优点是性能高效，并且由于它在 Internet 上的流行而易于理解。缺点是这种安全性是单独应用在通信路径中的每一跳上，使得通信容易受到中间人攻击。

废话。

虽然“TLS”本身可以很好地以这种方式使用，例如。在某些出于某种原因所有主机都受信任的 P2P 协议中，绝大多数用例是端到端系统（包括 HTTPS）。作者似乎对这个话题了解不多。

对于网站，据我们所知，HTTPS 足以防止 MITM。