在高层次上，它们是等效的。它们都是在两个端点之间创建“隧道”的“安全通信”协议。在此隧道内传输的数据受到机密性、完整性和身份验证的保护。

在实践中，TLS / SSL / DTLS和IPSec的（！和SSH）都被认为是安全同样作为协议-这是更多的使用的算法的选择中，使其中一个比另一个更安全的协议。（例如，3DES IPsec 不如 AES-128 TLS 安全，而 AES-256 IPsec 不如 AES-256 IPsec，依此类推）

但是，如果您深入研究每个人的内部工作原理，就会发现两者之间存在重大差异（尽管答案可能属于信息安全或加密堆栈交换）。

机密性由对称加密提供。完整性由MAC或消息验证代码提供。

传统上，这是在两个单独的操作中完成的——一个操作用于加密，另一个操作用于 MAC。那么问题是，如果有两个操作……应该先做哪一个？

TLS 和 IPsec 选择了不同的策略：

• TLS/SSL 执行MAC-then-Encrypt ——MAC 是在明文上计算的，结果摘要被附加，然后明文和摘要都被加密以产生密文。

• IPsec先加密然后MAC——明文先加密。然后对密文计算 MAC，并附加生成的摘要。

TLS/SSL 选择的策略最终成为两者中安全性较低的策略。主要是因为在接收端，你必须先进行解密操作，然后才能检查消息是否被篡改。这违反了一位白帽黑客所说的密码学末日原则。

因此，如果你剥离很多层，你会得出这样的结论： IPsec 比 TLS/SSL 更安全。

下一个问题是......为什么不是到处都使用它而不是TLS？

由于 IPsec 和 IKEv1 协商的工作方式，如果您必须使静态端点一致地相互连接，您可以使用不会推断出任何重大安全风险的主模式。

但是，如果您有两个非静态端点，例如...来自世界各地的 Web 浏览器，或从家/咖啡店/机场/酒店连接的远程员工，IKEv1 协商使用积极模式，不幸的是它确实泄漏了潜在的敏感信息信息。

（我在别处写过关于这个堆栈交换的主模式和激进模式，我会尝试挖掘链接并在此处添加它们）

TLS 没有这个问题...只要您使用当前版本的 SSL/TLS，远程主机或静态主机之间的协商是相同的。

此外，IPsec 通常需要在终端主机（VPN 客户端等）上运行的附加软件。TLS/SSL 的实现随所有操作系统和 Web 浏览器随处可见。这使得运行 TLS/SSL 软件的“成本”远低于必须安装 IPsec 软件。

最后让我们回答你的问题：

• 在端点连接是静态的情况下，传统的方法是使用 IPsec 构建站点到站点 VPN，因为它更安全。

• 在端点连接不是静态的场景下，传统的方法是使用TLS/SSL构建“安全隧道”，因为它更方便。

这成为如何使用 TLS/SSL 或 IPsec 来实现安全通信的首选标准方法。

也就是说……这种传统方法源自这些协议的历史。我想补充几点来说明现代：

• 当前对 TLS/SSL 的建议是使用 AEAD 密码，它以正确的顺序一步完成加密/MAC。如果您使用的是 AEAD 密码，则 TLS/SSL 之间没有安全漏洞
• 当前对 IPSec 的建议是使用 IKEv2，它不会泄露远程客户端的敏感信息

它们都提供身份验证和机密性。不同之处在于 TLS 是由应用程序配置的。换句话说，您的应用程序需要进行配置才能使用它。

另一方面，IPSec VPN 在网络层配置并为应用程序创建隧道。应用程序不知道正在使用 VPN。

你混合了两种不同的东西：

• VPN 作为隧道提供商与 SSL/TLS 用于特定应用程序加密
• 出于其他原因，基于TLS/DTLS 的IPsec

VPN 的要点是创建一个隧道链接，您可以在其中以安全的方式和私有寻址传递私有流量。VPN 可用于任何类型的流量，无需在应用层进行特定设置。IPsec 提供了这一点，但可能会受到意外或故意过滤的影响——在 TLS/DTLS 包装器内，它可能不那么显眼或“异国情调”并且更容易通过。因此，当普通 IPsec 失败时，一些远程访问产品会提供 TLS/DTLS 回退。

此外，VPN 即服务提供商可以在同一后端/中央基础设施上为多个客户终止 TLS/DTLS 用户隧道，但使用不同的内部 IPsec 隧道在客户网关上再次终止。这样，客户的网络可以与服务提供商的网络以及彼此之间完全分离（双 DMZ）。

DTLS 不能隐藏拓扑，而 IPSEC 可以。