SSL 是否应当在负载均衡器上卸载?(2)

如果你选择第一种方式,那么数据在嗅探系统(即负载均衡器)与集群之间的传输是不加密的,除非你选择其他的 SSL 通道对数据重新加密。在这种方式下,主要的 SSL 连接是在客户端与负载均衡设备之间,而后者会在其自身与每个集群的节点间维护一个 SSL link(或是选择其他某些加密技术,例如某种实现了 IPsec 的 VPN)。

第二种方式更轻量级一些,因为数据包嗅探器只需要对数据进行解密,而无需进行重新加密。不过,这也意味着服务器上的所有节点都能够与客户端进行完整的 SSL 通信,也就必须获取服务器的私钥信息。此外,由于不支持 DHE,也就代表你无法享受到 Perfect Forward Secrecy 特性所带来的好处(虽然问题不算特别严重,但是 PFS 对于安全审计来说非常实用,最好能够保留它)。

无论哪种方式,负责进行尝试数据包嗅探的节点必须获取 SSL 通道的某些访问特权,因此对于安全方面来说是个风险。

Ralph Bolton 则给出了一些具体做法的建议:

我也支持在负载均衡器(例如你自己的网络设备,或是第三方 CDN 提供商等技术)上卸载 SSL,这样可以使负载均衡器对流量进行嗅探,并更好地发挥负载均衡的功效。同时,这也意味着你的负载均衡器需要负责处理慢客户端、错误的 SSL 实现以及一般性的互联网的缺陷。为此,你可能要为负载均衡器投入更好的资源,而不是后端服务器。然后,这同样也表示在全世界通行的 SSL 证书都在负载均衡器上设置(希望这能够让维护这些证书的工作变得简单一些)。

有一种可选的方案是简单地将客户端的 TCP 连接均衡地在后端服务器上进行负载,由于负载均衡器在这种情况下无法了解具体细节,因此也无法在后端服务器上做到负载的平衡,而后端服务器也需要直接处理各种互联网的问题。对我来说,只有在对于负载均衡器、CDN 提供商等技术无法信任的情况下才会做出这种选择。

至于是否要在负载均衡器与后端服务器之间进行重新加密,则由你个人偏好与实际情况而定。如果你需要处理信用卡或金融交易,很可能受到政府的管控,那么就必须选择重新加密。另外,如果负载均衡器是通过不可信的网络与后端服务器之间进行流量交换,也应当选择重新加密。反之,如果你只是运行一个公司的网站,并且对于它的安全关心并不太在意,那么也可以选择免除重新加密带来的麻烦。

重新加密所带来的开销或许没有你想象中那么高,通常来说,负载均衡器能够与后端服务器之间维持一个长连接,SSL 的开销在这种网络中是非常小的。

最后需要考虑的一件事是后端服务器上运行的应用。如果所有到来的流量都是 HTTP 形式,则应用就无法根据客户端所使用的协议来进行相应的决策。举例来说,它无法做到"你正在尝试通过 HTTP 方式访问登录页面,我会将你重定向到该页面的 HTTPS 版本上"等操作。你或许可以让负载均衡器添加一个 HTTP header,以表示该请求原本来自于 HTTPS,但必须在应用中对于这个 header 进行特殊处理。在某些情况下,选择进行重新加密,并让应用以默认的方式运行,或许比起针对站点的情况而进行特殊的改造来得更合适。

我的结论是:在负载均衡器上进行卸载,并在发送至后端服务器时进行重新加密。如果按这种方式操作时遇到某些问题,而按需要进行一些调整。

最后的一个回答来自于用户 Davis:

你可以选择通过某种较简单的密钥证书对内部流量进行加密。另外,建议你尽量缩短负载均衡器与服务器之间的路径,以避免内部传输中的嗅探或攻击。SSL 可以在负载均衡器上进行卸载,以减轻 web 服务器处理这种 CPU 密集型任务的压力。而如果你选择的负载均衡设备品牌能够支持更丰富的功能,例如检测恶意协议连接、检测 DDoS 行为,那就更棒了。

查看英文原文:https://security.stackexchange.com/questions/30403/should-ssl-be-terminated-at-a-load-balancer

Linux公社的RSS地址:https://www.linuxidc.com/rssFeed.aspx

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/e55dcb5d960606ce4141499b5c57d2fe.html