反向代理安全配置

Question

我有一个最前沿的TMG 2010作为一个反向代理：

• 我可以在互联网客户端和TMG之间强制HTTP*S*。
• 我可以在TMG和我的web服务器之间强制HTTP*S*。

从安全的角度来看，在互联网客户端和TMG之间强制使用HTTPS是一种最佳实践(如果我错了，请纠正我)。这将允许反向代理解密通信量并对其进行攻击分析。这是正确的吗？

但是TMG和网络服务器之间的流量呢？你会强迫它是HTTPS吗？如果是，这样做有什么安全好处？

Answer 1

标准的答案是，使用从前端到后端服务器的安全连接。

在以下情况下，使用未加密的连接可能是正常和常见的：

1. 前端和后端之间的网络基础设施被认为是安全的。例如，一个专用的硬件网络，它确保没有任何未经授权的嗅探或修改流量是可能的。应该以一种防止ARP缓存中毒和ARP缓存泛滥的方式设置开关，因为服务器可能会成为攻击的受害者并变成敌对的。
2. 而且流量太高，以至于解密在后端服务器上造成了很大的负载。

Answer 2

SSL的性能成本很高--特别是对于HTTP。OTOH是防止MITM和窃听的最实用的方法--当功能/可用性受到影响时，只有在需要保护的地方添加保护才是“最佳实践”。

如果代理和are服务器之间存在窃听/MITM的风险，那么保护连接是有意义的--然而，这种情况很少发生(除非代理是CDN的一部分)。

“并分析它的攻击”--终止代理上的SSL意味着您依赖代理提供的功能进行任何分析，这取决于您可能如何实现，例如，SSL服务器上没有客户端证书的可见性。请注意，对于SSL，如果代理是真正的HTTP代理，那么它将解码SSL并再次对其重新编码--因此，与在代理和when服务器之间不使用SSL相比，您对客户端代理SSL行为没有更大的可见性。

Answer 3

在TMG和最终用户之间运行SSL的主要原因与您运行任何VPN的原因相同--您在与客户交谈时需要隐私和身份验证。例如，你不希望任何有回溯CD的白痴在被访问时能够浏览你的Sharepoint或OWA。更糟糕的是，并非所有的企业应用程序都足够聪明，可以使用强大的密码管理或cookie管理技术，而且您也不希望这些信息泄漏。

仅仅因为它是一个web应用程序并不意味着它不需要一个VPN，并且TMG和客户端之间的HTTPS会选中这个框。