SSL 是否应该在负载平衡器处终止?

信息安全 tls 网络 防火墙
2021-08-12 01:40:40

在托管 Web 应用程序服务器集群时,通常会在集群和公共 Internet 之间使用反向代理(HAProxy、Nginx、F5 等)来对应用程序服务器之间的流量进行负载平衡。为了执行深度数据包检查,SSL 必须在负载均衡器(或更早)处终止,但负载均衡器和应用服务器之间的流量将是未加密的。提前终止 SSL 不会让应用服务器容易受到数据包嗅探或 ARP 中毒的影响吗?

是否应该卸载 SSL?如果是这样,如何在不损害所服务数据的完整性的情况下做到这一点?我主要关心的是不能选择消息层加密的 Web 应用程序。

4个回答

在我看来,问题是“您是否信任自己的数据中心”。换句话说,您似乎正在尝试精细地划定不受信任的网络所在的位置,然后信任就开始了。

在我看来,SSL/TLS 信任应该终止于 SSL 卸载设备,因为管理该设备的部门通常还管理网络和基础设施。那里有一定数量的合同信任。在下游服务器上加密数据是没有意义的,因为支持网络的人通常也可以访问它。(在多租户环境中可能存在例外,或者需要更深入细分的独特业务需求)。

SSL 应该在负载均衡器处终止的第二个原因是因为它提供了一个集中的位置来纠正 SSL 攻击,例如CRIMEBEAST如果 SSL 在各种 Web 服务器上终止,在不同的操作系统上运行,由于额外的 复杂性,您更有可能遇到问题保持简单,从长远来看,你会遇到更少的问题。

话虽如此

  1. 是的,在负载平衡器处终止并在那里进行 SSL 卸载。把事情简单化。
  2. Citrix Netscaler 负载均衡器(例如)可以拒绝对 URL 的不安全访问。此策略逻辑与 TLS 的功能相结合应确保您的数据保持机密和不可篡改(鉴于我正确理解您对完整性的要求)

编辑:

有可能(并且很常见)

  • 外包负载均衡器(亚马逊、微软等)
  • 使用第三方 CDN(Akamai、Amazon、Microsoft 等)
  • 或使用第 3 方代理来防止 DoS 攻击

...来自该第 3 方的流量将通过您不管理的网络链接发送到您的服务器。因此可能不信任那些未加密的链接。在这种情况下,您应该重新加密数据,或者至少让所有数据通过点对点 VPN 传输。

Microsoft 确实提供了这样的 VPN 产品,并允许外围安全外包。

是的,我认为应该卸载 TLS。我已经用 Citrix Netscaler 完成了下面提到的所有事情,但我相信 F5 应该能够做同样的事情。

首先,您始终需要确保在负载均衡器的另一端重新加密,但解密 TLS 的设备应该能够从安全角度检查正在发生的事情。这种方法不应损害数据的完整性。

许多人对我说,在后端重新加密会导致计算成本高昂,但事实并非如此。TLS 的开销是建立和关闭连接,由 TLS 卸载程序处理。在后端,您与服务器的连接更持久,因此所需的资源要少得多。

此外,如果您没有 TLS 卸载,那么即使是通过 TLS 进行的小型 DDoS 攻击也会彻底摧毁您的服务器。我对这种情况非常熟悉,从计算的角度来看,TLS 卸载是一个难以置信的帮助,并且还允许您进一步阻止攻击链。对于超大型 DDoS 攻击,您甚至可以在 TLS 卸载程序和服务器之间拆分缓解策略。

要检查 SSL 连接中的数据,则必须满足以下任一条件:

  • 隧道在进行检查的机器上结束,例如您的“负载平衡器”。
  • 检查系统知道服务器私钥的副本,并且 SSL 连接不使用临时 Diffie-Hellman(即服务器不允许名称中包含“DHE”的密码套件)。

如果您遵循第一个选项,则数据将在检查系统(负载均衡器)和集群之间以未加密方式传输,除非您使用其他 SSL 隧道重新加密它:主 SSL 连接在客户端浏览器和负载均衡器之间,负载平衡器在它自己和每个集群节点之间维护一个 SSL 链接(或一些其他加密技术,例如带有IPsec的 VPN)。

第二个选项稍微轻一些,因为数据包检查器只是解密数据,而不必重新加密它。然而,这意味着所有集群节点都能够与客户端进行完整的 SSL,即知道服务器私钥的副本。此外,不支持 DHE 意味着您将无法获得Perfect Forward Secrecy的漂亮功能(这不是致命的,但 PFS 在安全审计中看起来非常好,所以拥有它是一件好事)。

无论哪种方式,执行深度数据包检查的节点都必须对 SSL 隧道具有一定的特权访问权限,这使得它对安全性至关重要。

我会提倡在负载均衡器上终止 SSL(无论是在您的网络上,还是在 CDN 提供商或其他地方)。这意味着 LB 可以检查流量并可以更好地进行负载均衡。这也意味着您的负载均衡器负责处理缓慢的客户端、损坏的 SSL 实现和一般的 Internet 不稳定。与后端服务器相比,您的负载平衡器可能有更好的资源来执行此操作。这也意味着全世界看到的 SSL 证书都在负载均衡器上(这有望使它们更易于管理)。

这里的替代方法是简单地对从客户端到后端服务器的 TCP 连接进行负载平衡。由于 LB 无法以这种方式检查正在发生的事情,它无法将负载均匀地分布在后端服务器上,后端服务器必须处理所有 Internet 脆弱性。如果您不信任您的负载均衡器、CDN 提供商或其他任何东西,我只会使用此方法。

是否从负载均衡器重新加密到后端服务器是个人选择和环境的问题。如果您正在处理信用卡或金融交易,那么您可能受到政府的监管,因此必须重新加密。如果负载均衡器和后端服务器之间的流量通过不受信任的网络传输,您可能还应该重新加密。如果您只是托管您公司的网站,那么您可能能够避免重新加密的额外开销,如果您并不真正关心它的安全方面。

重新加密并没有像您想象的那样增加负载。通常,负载平衡器将能够保持与服务器的持久连接,因此对于网络上的“跃点”,SSL 成本将非常低。

最后要考虑的是后端服务器上的应用程序。如果到达那里的所有流量都是 HTTP,那么它就无法根据客户端使用的协议做出决定。例如,它不能说“您正在尝试通过 HTTP 访问登录页面,所以我会将您重定向到该页面的 HTTPS 版本”。您可以让负载均衡器添加一个 HTTP 标头来表示“这来自 HTTPS”,但该标头需要在应用程序中进行特殊处理。根据您的情况,重新加密并让应用程序以“默认”方式工作可能会更容易,而不是需要特定于站点的修改。

总之,我想说:在负载均衡器处终止并重新加密到您的后端服务器。如果您这样做并注意到一些问题,那么您可以根据需要进行调整。