http到https重定向的安全性

Question

我有一个100％https的网站，只能用作https。我的网站是一个运行在IIS 7.5上的asp.net mvc应用程序。

它在多个服务器上通过负载均衡器分配流量。

我不控制硬件。

对于http请求，我希望它可以在负载平衡器处停止，并在此时重定向到https。

但是硬件公司不会为我做这件事，而是需要在服务器上的IIS中执行从http到https的重定向。因此，未加密的业务可以通过在服务器级别重定向进入内部网络。在负载平衡器上发生这种转移时，我会感到更加舒适。

我是否有有效的担忧？

Answer 1

威胁模型：不管

HTTP request: 

      Attacker 
       |   Security Boundary 
       V   V 
Client -- http request --> Load Balancer 
           | 
Client <-- redirect -----------+ 

威胁从允许HTTP发生重定向方法论：

• 欺骗：客户端可以连接到中间人欺骗不通过重定向HTTP服务器，但而是代理连接到实际的HTTPS服务器
• 篡改：客户端可以从MITM欺骗服务器接收重定向URL，将它们引导到另一个动作（例如：客户端接收重定向到https://yoursite.com/login.aspx?redirect=/deleteAllDocuments）
• 信息披露：披露了初始HTTP请求，POST或GET中的任何信息都可用于未加密的窃听者。

参数进行重定向比目标服务器其他服务器：

• 防火墙可以限制为HTTPS数据，限制了由于配置错误未加密数据的风险
• 配置和负债可能成为“别人的问题“，至少从政治角度来看
• HTTP服务器中的漏洞将被隔离，无法用于攻击HTTPS服务器或基础应用程序

参数用于执行重定向比负载平衡器以外的东西：

• 负载平衡器不是服务器
• 负载平衡器不是服务器，因此还不如服务器，用于当已不常使用的代码路径，其可能是更容易出现未发现的bug或性能问题
• 配置不提供给你，但你（或你的公司）仍然可能对发生的任何错误的配置容易（从法律的角度）

在上面的分析中，最高的安全性与风险最低的光：

• 我会不把目标服务器上的重定向，也不是负载均衡，而是在虚拟机上只用于重定向页面。最小的Linux或Windows应该能够被紧紧锁定以限制暴露。
• 我不会允许与查询字符串或POST的数据（例如：显示404对于任何非GET/HTTP/1.1请求）重定向
• 我称之为欺骗的可能性和篡改可接受的风险，或显示一个页面到用户解释，该网站必须使用HTTPS而不是使用重定向

但是，如果你可以假设满足以下条件，将HTTP服务器共同驻留与HTTPS服务器不应该减少安全访问。

• 在HTTP服务器的任何错误存在于HTTPS服务器
• HTTP服务器被正确地配置为禁止访问受保护资源（设置为IIS中的单独的站点，例如，安全站点仍然有没有HTTP绑定）
• 没有其他应用程序能够创建在HTTP服务器（netsh urlacl只有IIS，例如）
• 配置被审计，以确保上述构造适当地保持（定期笔的测试中，手工配置的综述，配置变更管理以及IDS或IPS系统）

在某些情况下，降低的复杂性甚至比单独的服务器更容易安全。另外，如果管理员不熟悉负载平衡器的配置，他们可能更倾向于在配置中发生严重错误，而不是在他们熟悉的产品中进行相同配置。

Answer 2

我有没有有效的担忧？

您是否对通过HTTP进行初始连接有一个有效的关注？当然。最初的请求可以被拦截，并且在MitM攻击中可以欺骗回应。然后，攻击者可以阻止用户使用HTTP（在攻击者和服务器之间添加ssl/tls，并以明文方式中继给受害者），或者可以与客户端建立一个冒充者SSL会话，加密的方式给你（使用各种欺骗技术使攻击对临时用户不太明显）。

但是，如果发起这样的攻击，我会远更担心从客户端到您的负载平衡器，而不是您的负载平衡器和IIS之间的转移。如果您怀疑您的负载均衡器背后有恶意系统，则会遇到完全不同的问题。

Answer 3

有关从HTTP重定向到HTTPS的一些相关信息，请参阅my answer而不是security.so。