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

是否应卸载SSL?如果是这样,如何在不影响所提供数据完整性的情况下完成此工作?我主要关心的是无法使用消息层加密的Web应用程序。

评论

有趣的是,在2013年发布此问题仅几个月后:遇到“肌肉”:NSA被指控利用Yahoo,Google数据中心,Google,NSA之间的链接,以及需要锁定数据中心流量,Google Boosting Encryption在数据中心之间,...

有趣。那么现在推荐在所有地方使用HTTPs吗?即使在VPC中?亚马逊等是否建议在AWS文档中这样做?

#1 楼

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

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

SSL应该在负载平衡器处终止的第二个原因是,它提供了一个集中的位置来纠正SSL攻击,例如CRIME或BEAST。如果SSL在各种Web服务器上终止,并且在不同的OS上运行,则由于额外的复杂性,您更有可能遇到问题。保持简单,从长远来看,您将遇到的麻烦更少。 。保持简单。
Citrix Netscaler负载平衡器(例如)可以拒绝对URL的不安全访问。这种策略逻辑与TLS的功能相结合,可以确保您的数据保持机密和不受篡改(假设我正确理解了您的完整性要求)



将负载平衡器(Amazon,Microsoft等)外包的可能性(和通用)
使用第三方CDN(Akamai,Amazon,Microsoft等)
>或使用第三方代理来防止DoS攻击

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

Microsoft确实提供了这样的VPN产品,并允许将周边。

评论


如果我不在自己的数据中心内使用负载平衡器,而在CDN中使用该怎么办?例如。 Cloudflare具有“灵活SSL”模式,在此模式下,SSL到CDN,然后是非SSL到原始服务器。也许这与情景完全不同,值得提出自己的问题?

–泰勒·科利尔(Tyler Collier)
14年7月31日在22:58

@TylerCollier感谢您的评论。我澄清了

–半比特
2014年7月31日23:46

如果您处于安全的托管环境中,那么您对自己的计算机(位于物理机架内)的信任程度自然要比对数据中心的信任程度高。

– Lie Ryan
2014年8月1日,0:03

@LamonteCristo:在涉及多个数据中心的情况下,假设在满足请求之前,流量达到了美国的dc1,日本也达到了dc2,因此在这种情况下,重新加密流量很有意义在dc1和dc2之间,对吗?

– Piyush Kansal
15年4月17日在8:18

@PiyushKansal一些公司在这些实例中具有网络层VPN,因此您不必担心这一点,但是如果不存在,我会重新加密。我不知道您的具体情况,但是可能需要考虑一些事情,例如SafeHarbor(safeharbor.export.gov/list.aspx)信任列表,以及贵公司在像您这样的国际情况下的法律责任

–半比特
2015年4月17日10:11



#2 楼

是的,我认为应该卸载TLS。我已经使用Citrix Netscaler专门完成了下面提到的所有操作,但是我相信F5应该能够执行相同的操作。

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

许多人对我说,后端重新加密使其在计算上同样昂贵,但这不是事实。 TLS的开销是建立和关闭TLS卸载程序处理的连接。在后端,您与服务器的连接更加持久,因此所需的资源要少得多。

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

评论


+1用于在另一侧重新加密。作为.NET开发人员,我想通过像这样的配置来确保将SSL / TLS用于cookie。但这仅在负载均衡器本身后面的应用程序服务器通过https获得连接时才有效。

–马塞尔
16年7月8日在6:13

还要注意,您实际上必须对从负载均衡器到其背后的服务器的连接进行身份验证,否则无论如何您仍然会受到各种攻击(例如MITM)。我发现有趣的是,许多“云”负载平衡器将对后端执行TLS,但无需进行身份验证。

– cjs
17年5月18日在7:54



#3 楼

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


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

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

第二个选项是因为数据包检查器仅解密数据而不必重新加密,因此它的重量要轻一些。但是,这意味着所有群集节点都能够对客户端执行完整的SSL,即知道服务器私钥的副本。另外,不支持DHE意味着您将不会获得Perfect Forward Secrecy的漂亮功能(这不是致命的,但是PFS在安全审核中看起来确实不错,所以这是一件好事)。

无论哪种方式,执行深度数据包检查的节点都必须具有对SSL隧道的某些特权访问,这对于安全性而言至关重要。

#4 楼

我建议在负载均衡器(在您的网络,CDN提供程序或其他任何设备)上终止SSL。这意味着LB可以检查流量并可以更好地进行负载平衡。这也意味着您的负载均衡器负责处理速度慢的客户端,破坏的SSL实施和一般的互联网脆弱性。您的负载均衡器可能比后端服务器有更多的资源来执行此操作。这也意味着,世界范围内看到的SSL证书都在负载平衡器上(这有望使它们更易于管理)。后端服务器。由于LB无法检查这种方式所发生的情况,因此它无法在后端服务器之间平均分配负载,并且后端服务器必须处理所有Internet脆弱性。如果您不信任负载均衡器,CDN提供程序或其他任何东西,我只会使用此方法。个人选择和情况。如果您要处理信用卡或金融交易,那么您可能会受到政府的监管,因此必须重新加密。如果负载平衡器和后端服务器之间的流量正在不受信任的网络上传输,则可能还应该重新加密。如果您只是托管公司的网站,那么即使您真的不在乎它的安全性,也可以避免重新加密的额外开销。

重新加密不会增加您可能想到的负载。通常,负载平衡器将能够维持与服务器之间的持久连接,因此对于网络上的“跃点”来说,SSL成本将非常低。

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

#5 楼

您可以选择使用低调证书对内部流量进行加密。此外,还建议将负载均衡器放置在尽可能靠近服务器的位置,以防止嗅探或中间人攻击。可以在负载均衡器上完成SSL终止,以将CPU密集型工作从Web服务器上转移下来。如果您选择的LB品牌可以执行某些功能,例如检查格式错误的协议连接,检测DDoS行为等。