是否应该在负载均衡器上卸载 SSL？

StackExchange 用户 Matt Goforth 对负载均衡器中的 SSL 处理表示怀疑：

对于集群 Web 应用程序，常见的方法是将集群连接到公共网络。添加反向代理（例如 HAProxy、Nginx、F5 等）以对应用服务器流量进行负载平衡。对于深度数据包检查，必须在负载平衡层（或早期阶段）卸载 SSL。但是，这样负载均衡器和应用程序服务器之间的流量是未加密的。入口处的 SSL 卸载是否会给应用服务器带来数据包嗅探或 ARP 欺骗风险？

是否应该卸载 SSL？如果答案是肯定的，在不损害数据传输完整性的情况下可以做什么？我主要担心的是那些本身无法实现消息层加密的 Web 应用程序。

在这个问题的得票最高的答案中，用户CHI Coder 007说：

我认为你的问题主要是关于“你信任你的数据中心吗？”换句话说，您似乎正在尝试找到一方面不受信任的网络与另一方面受信任的来源之间的分界线。

在我看来，SSL/TLS 信任应该终止于 SSL 卸载设备级别，因为管理这些设备的部门通常还负责网络和基础设施管理。信任的很大一部分是契约性的。加密下游服务器传输的数据是没有意义的，因为通常负责网络的人员也可以访问这些服务器（可能有一些例外，例如多租户环境或强制某些业务需求需要更深层次的隔离）。

在负载均衡器上加载 SSL 的另一个原因是它是处理 CRIME 或 BEAST 等 SSL 攻击的核心。如果您选择将 SSL 卸载到运行不同操作系统的各个 Web 服务器，则可能会由于增加的复杂性而遇到问题。从长远来看，让问题尽可能简单会为您省去麻烦。

简而言之
1. 是的，SSL 卸载应该在负载均衡器上完成，以使事情变得更容易。
2.（例如）Citrix Netscaler 可以防止对特定 URL 的不安全访问。将此策略逻辑与 TLS 相关功能相结合可以确保您的数据受信任且无法被篡改（假设您对数据完整性要求的理解是正确的）。

但是，您可能会遇到以下情况（也比较常见）：
使用外部提供的负载平衡服务（例如 Amazon 和 Microsoft 服务）
b.使用第三方CDN（例如Akamai、Amazon、Microsoft等）
c.或者使用第三方代理来避免 DoS 攻击。

在这种情况下，第三方流量会通过您无法控制的网络链接发送到您的服务器。服务器，这些未加密的链接可能不可信。在这种情况下，您应该重新加密您的数据，或者至少通过点对点
VPN 传输数据。

Microsoft 提供了这样的 VPN 产品，允许您将网络外围的安全性转移到它身上。

用户JZeolla也同意这种做法：

是的，我也同意TLS卸载的想法。我在Citrix Netscaler中尝试了以下方法，但相信F5也能实现相同的功能。

首先需要确保数据在负载均衡器的另一端重新加密，但 TLS 解密设备
应该能够从安全角度检测到问题。这种方法不应成为降低数据完整性的借口。

很多人告诉我，在后端重新加密会是一个巨大的计算负担，但事实并非如此。 TLS资源消耗来自于连接的建立和关闭，由TLS卸载器完成。在后台程序中，您与服务器有更持久的连接，这显着减少了资源消耗。

此外，如果您不卸载 TLS，即使是通过 TLS 发起的小型 DDos 攻击也可能完全瘫痪您的服务器。我非常熟悉这种场景，卸载 TLS 可以在计算上产生很大的影响，并允许您在入口阶段阻止攻击。对于非常大的 DDoS 攻击，您还可以在 TLS 卸载器和服务器之间共享缓解措施。

用户 Tom Leek 对 SSL 连接中的数据嗅探给出了更详细的解释：

为了嗅探通过 SSL 连接传输的数据，必须满足两个条件之一：

1。转发 通道终止于负责嗅探的机器，您将其称为“负载均衡器”。
2. 嗅探系统已获得服务器私钥的副本，并且 SSL 连接不使用短期 Diffie-Hellman 密钥交换算法（这意味着服务器不允许其密码套件中包含“DHE”）名称）。)

如果您选择第一种方法，嗅探器系统（即负载均衡器）和集群之间的数据传输将是未加密的，除非您选择其他 SSL 通道来重新加密数据。在此方法中，主要 SSL 连接位于客户端和负载均衡器之间，负载均衡器在其自身和集群中的每个节点之间维护 SSL 连接（或选择实现另一种加密技术（例如 IPsec）的 VPN）。

第二种方法更简单，因为数据包嗅探器只需要解密数据而无需重新加密。但是，这也意味着服务器上的所有节点都可以与客户端进行完整的SSL通信，并且必须获取服务器的私钥信息。另外，由于不支持 DHE，这意味着您无法享受 Perfect Forward Secrecy 的好处（虽然不是一个严重的问题，但 PFS 对于安全审计非常有用，最好保留）。

在这两种情况下，负责数据包嗅探尝试的节点必须获得 SSL 通道的访问权限，因此存在安全风险。

Ralph Bolton 提出了一些具体的建议：

我还支持将 SSL 卸载到负载均衡器（例如您自己的网络设备或第三方 CDN 提供商等技术），以便负载均衡器可以嗅探流量并执行更好的负载平衡。同时，这也意味着您的负载均衡器必须对缓慢的客户端、不良的 SSL 实施和一般的 Internet 问题负责。因此，您可能希望将更多资源分配给负载均衡器而不是后端服务器。然而，这也意味着世界各地使用的 SSL 证书将在负载均衡器中设置（希望使维护这些证书变得更容易）。

另一种方法是简单地在后端服务器上对客户端的 TCP 连接进行负载平衡。由于负载均衡器不了解这种情况下的具体情况，因此无法在后端执行此操作。为了平衡负载，后端服务器还要处理各种互联网问题。对我来说，只有在负载均衡器、CDN 提供商等技术不可信的情况下才会做出这种选择。

负载均衡器和后端之间是否重新加密取决于您的个人喜好和实际情况。如果您需要处理可能受政府监管的信用卡或金融交易，则需要再次选择加密。此外，如果负载均衡器通过不受信任的网络与后端服务器交换流量，您还应该选择重新加密。另一方面，如果您只是管理公司网站并且不太关心其安全性，则可以避免重新加密的麻烦。

重新加密带来的开销可能没有您想象的那么大。一般来说，负载均衡器可以维持与后端服务器的长连接，并且在此类网络中SSL开销非常低。

最后要考虑的是后台服务器上运行的应用程序。如果所有传入流量都是 HTTP，则应用程序无法根据客户端使用的协议做出决策。例如，它不能执行诸如“您正在尝试通过 HTTP 访问登录页面，我会将您重定向到该页面的 HTTPS 版本”之类的操作。也许您可以让负载均衡器添加一个 HTTP 标头，指示请求最初来自 HTTPS，但必须在应用程序中专门处理该标头。在某些情况下，与其对站点进行特殊更改，不如重新加密并让应用程序在默认模式下运行可能更合适。

我的结论：下载负载均衡器，发送到后端时重新加密。如果您以这种方式工作时遇到问题，请根据需要进行一些调整。

最后一个答案来自用户Davis：

内部流量可以通过一些更简单的密钥证书进行加密。另外，建议负载均衡器和服务器之间的路径尽可能短，以避免内部传输中的窥探或攻击。 SSL 可以卸载到负载均衡器上，以减轻 Web 服务器的 CPU 密集型任务。如果您选择的负载均衡器品牌支持恶意协议连接检测、DDoS行为检测等更丰富的功能就更好了。