因为害怕攻击者可能窃取了私钥而拒绝 TLS 就像因为害怕有人毒害药物而拒绝药物一样。缺点远远超过不使用它的风险。

为什么 TLS 是安全的

有很多角度可以回答这个问题，但不言而喻的是每个人都在使用它。政府机构正在使用它，大型科技公司正在使用它，银行正在使用它，医院正在使用它，StackExchange 也在使用它。如果 TLS 不安全，您不认为至少有人会认为使用它并切换到其他人是个坏主意吗？TLS 几乎无处不在，而且每个人都在到处推荐，这一事实应该告诉您，使用它是个好主意。

此外，如果配置正确，TLS 是安全的。1.3 版让这变得很容易，截至撰写本文时，配置 TLS 1.3 的方法没有错误。TLS 1.2 有点困难，因为 TLS 1.2 中有一些不安全的密码。SOGIS - 也使用 TLS - 有一个广泛的指南，关于推荐哪些密码，以及哪些密码仍然可以容忍遗留使用。

最后，导致不安全通信的私钥泄露并不是 TLS 的一些其他协议可以缓解的缺陷——它是网络通信固有的缺陷。如果您假设攻击者可以完全控制您的服务器，那么无论您使用什么协议，攻击都能够解密任何流量、操纵任何流量并伪造新流量。

换句话说，TLS 并非旨在防止服务器受损，而且无论是 TLS 还是 TLS 的替代品——无论是自制的还是其他的——都不能防止这种情况发生。

TLS 的替代方案

由于问题要求 TLS 的替代方案，因此有一个：DTLS

DTLS 基本上是 TLS，但用于 UDP。您可能想要使用 DTLS 的原因是因为您的应用程序使用 UDP 而不是 TCP（例如 VoIP 程序），但您仍然希望对数据报进行加密。

DTLS 并不比 TLS 更安全或更不安全，而是旨在与不同的底层一起工作。

对于 Web 客户端，你很不走运，浏览器支持的仅有的两种协议是 HTTP（没有任何安全性）和 HTTPS（使用 TLS）。

对于移动应用程序，如果您确实必须使用 TLS 1.3 以外的其他协议，我的建议如下：

首先，您可以使用libsodium 之类的库来加密数据并处理任何加密函数。在应用程序中拥有服务器的公钥以对服务器进行身份验证。要对客户端进行身份验证，您可以从用户的密码中派生出一个密钥。

其次，这是最重要的，通过 HTTPS 在 TLS 1.3 隧道中传输这些加密数据。通过这种方式，您可以告诉您的管理层，您在 TLS 被破坏的情况下具有弹性，但您仍然可以从 TLS 提供的所有安全性中受益，而这些安全性是您无法通过自定义实现实现的。

您可以尝试使用 JavaScript 加密库为您的 Web 应用程序做类似的事情。但是，请记住，这只是为了缓解管理要求。在实践中，这增加了针对主动窃听者的零安全性。JavaScript 加密仅在用户信任服务器和连接时才有用，后者需要 TLS。

此外，您可以使用 TLS 使用的密码套件的全名来命名，而不是命名您的协议 TLS，例如“ECDHE_RSA_WITH_AES_GCM_SHA256”（它是 security.stackexchange.com 的当前套件）。

这似乎是一个 XY 问题。问题是“管理层担心与 TLS 相关的攻击的可能性。如何在 TLS 上进行更多加密？”。其他答案涵盖了如何对附加加密进行分层，以及为什么不应该这样做，但让我们看看应该如何处理真正的问题：管理层的担忧。让我们将他们的担忧转化为我们可以建模的威胁。

您提到的一种威胁是服务器私钥被泄露。这不会自动导致您的用户受到威胁，因为攻击者还需要拦截您的用户和服务器之间的流量。这并非不可能（有一些攻击可以实现这一点，例如 DNS 或 BGP 相关的攻击，或者您的用户使用虚假 WiFi 热点，如果他们可以与用户进入同一本地网络，则可能是一些 ARP 攻击），但它确实需要第二个漏洞。

您可以在此处添加一些缓解措施。一种是经常轮换您的服务器密钥，这样攻击者就无法长时间访问。将您的服务器密钥保存在硬件安全模块中也使得这一点更难被利用。另一个是仅支持具有前向保密性的密码套件，因为这需要攻击者主动拦截，而不是被动地窃听您的通信。如果您的应用程序支持它，您可以使用客户端证书，这意味着攻击者需要同时获得客户端和服务器证书才能成功地 MITM 连接。另一个重要的缓解措施是在您的服务器上进行入侵检测。您还可以潜在地监控 BGP 和 DNS 相关异常，这将防止攻击升级到可利用点。

您还提到 MITM 是一种可能的威胁。这是前面提到的风险的另一面，并且再次需要额外的休息才能变得可利用。泄露的服务器证书是其中之一（如前所述），但还有其他一些，例如证书错误颁发或 SSL 剥离。

您可以通过主动监控证书错误发行来减轻 MITM 风险。检查https://crt.sh以获取为您的域颁发的新证书。如果您控制通信的双方，则可以通过完全不使用或信任来自公共 CA 的证书，而是从内部 CA 颁发证书来消除证书错误颁发的可能性。您还应该查看 HSTS 和潜在的 HPKP（尽管后者有其自身的风险）。如果您的服务仅在明确定义的地理区域内提供，GeoIP 阻止也可能有所帮助。客户端证书在这里也有帮助。安全 cookie 也可以帮助解决 SSL 剥离风险。

所以剩下的问题变成了可以采取哪些缓解措施来抵御攻击者的威胁，这些攻击者既成功获得了您的域的服务器私钥，又对您的用户进行了中间人？在这一点上，可能值得一提的是，纵深防御虽然有价值，但也有代价：复杂性。新措施增加的复杂性可能会增加比它们减轻的表面积，从而增加更多的风险。如果您已经获得了上面详述的大部分缓解措施，那么这将成为一个非常不可能的威胁。

尽管如此，这里还是有一些可能可行的缓解措施。一种是设计具有数据级加密的系统，服务器没有密钥（只有用户有）。这样，即使您的服务器完全受到威胁，您的系统也可能仍然有些安全。另一个只是限制对 Web 界面的信任程度 - 也许您可以确保无法从公共 Web 界面执行管理操作，只能从只能从您的内部网络访问的内部界面执行。带外确认高价值操作也可能有所帮助（例如，电话用户在他们要求执行高价值操作时进行确认）。

但正如其他人所指出的，这些风险可能并不是您的应用程序面临的最紧迫的问题。攻击者识别具有已知漏洞的现成组件、识别 SQL 注入漏洞、发现您的一个 API 没有进行应有的授权检查、发现泄露您的 AWS 密钥的 SSRF 漏洞的威胁，找到具有 CSRF 或 XSS 弱点的端点、在不安全的 S3 存储桶中发现用户数据或帐户凭据、打电话给您的支持台声称自己是系统管理员但忘记了密码，或者只是发起 DDoS 攻击的可能性远大于问题中的威胁。

现在有人担心通过 MITM 攻击和泄露服务器私钥以任何方式绕过 TLS。

除了 TLS 之外，还有什么解决方案可以保护传输中的数据吗？

如果您假设服务器的私钥可以泄露，则没有已知的加密方案可以防止 MITM 攻击。任何解决方案都会有同样的漏洞。

针对 MITM 攻击的最著名的防御措施是使用证书。TLS 已经支持这一点。

最著名的防止服务器私钥泄露的防御措施是 HSM。TLS 已经支持这一点。