StackExchange 网站的一名用户 Matt Goforth 对于 SSL 在负载均衡设备上的处理提出了他的疑惑：
对于集群式的 web 应用来说，一种常见的做法是在集群与公网之间添加一道反向代理（例如 HAProxy、Nginx 和 F5 等等），以实现应用服务器的流量负载均衡。为了对数据包进行深入探测，必须在负载均衡这一层（或者是更靠前的阶段）将 SSL 进行卸载。但这样一来，负载均衡与应用服务器之间的流量就处于未加密的状态。这种在入口处对 SSL 进行卸载的做法是否会为应用服务器带来数据包嗅探或 ARP 欺骗的风险呢？
SSL 是否应该被卸载呢？如果答案是肯定的，要怎样做才不会降低数据传递的完整性呢？我主要担心的地方在于 web 应用，它本身是无法实现消息层的加密的。
在这个问题的最高票回答中，用户 CHI Coder 007 表示：
在我看来，你的问题主要在于 "你是否信任你的数据中心"。换句话说，看起来你正试图找到一条分界线，一边是无法信任的网络，另一边则是可信赖的起点。
按我的观点来看，SSL/TLS 信任应当在 SSL 卸载设备这一层就结束了，原因在于管理这些设备的部门通常也负责网络与基础设施的管理。这里面有很大一部分信任是受到契约的约束的。而对于下游服务器的传输数据加密是没有意义的，因为通常来说，负责网络的人员往往也能够访问到这些服务器（这里面可能会有一些例外，比如多租户环境，或是某些业务需求强制要求更深入的分离性）。
在负载均衡上卸载 SSL 的第二个原因在于，它是处理 SSL 攻击，例如 CRIME 或 BEAST 等行为的中央核心。如果你选择在运行着不同操作系统的各个 web 服务器上卸载 SSL，很可能会因为额外的复杂度而遇到各种问题。将问题尽量简单化，从长期来看将减少你的麻烦。
简而言之，
1. 是的，应当在负载均衡设备上完成 SSL 卸载，让问题简单化。
2.（举例来说）Citrix Netscaler 能够阻止对某个 URL 的不安全访问，将这种策略逻辑与 TLS 的相关特性相结合，就能够确保你的数据可靠，不被篡改（假设我对于你的数据完整性需求的理解是正确的）。
不过，你有可能遇到以下情形（也是比较常见的）：
a. 使用外部提供的负载均衡服务（例如亚马逊和微软的服务）
b. 使用第三方的CDN （例如 Akamai、亚马逊和微软等等）
c. 或是使用第三方代理以避免 Dos 攻击
在这些情况下，来自第三方的流量将通过你所无法控制的网络链接发送至你的服务器，这些未加密的链接有可能是不可信的。在这种情况下，你应当重新对数据进行加密，或者至少通过点对点的
VPN 进行数据传输。
微软就提供了这样一种 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" 的密码集。）