将 http 重定向到 https 是个坏主意吗？

小开

我没有看到从 HTTP 重定向到 HTTPS 的任何技术风险(除了在我的回答结尾的更新中的一个)。例如，gmail 和雅虎邮箱正在这样做。您可以通过使用 HTTP 调试工具(如 Fiddler)来检查这一点，您可以清楚地看到服务器返回的302重定向响应。

我认为从可用性的角度来看，阻塞是一个坏主意。很多时候，用户在浏览器中输入地址时没有指定 HTTP 或 HTTPS。例如，我通过输入“ mail.google.com”访问 gmail，默认为“ http://mail.google.com”，自动重定向为“ https://mail.google.com”。如果没有自动重定向，我将总是必须键入完整的地址。

我同意引用的文章说 HTTPS 是对抗 MITM 攻击的最佳方法，但我不同意它是对抗仿冒的最佳实践。用户教育确实是防止钓鱼攻击的一个关键因素(用户必须检查他们是否从正确的域访问站点) ，但是不能通过阻止 HTTP 重定向到 HTTPS 来进行这种教育。

更新佩德罗和斯波托是对的。必须特别注意与敏感 Cookie (如会话或身份验证 Cookie)相关的内容，这些 Cookie 确实应该标记为安全的，以便它们只能通过 HTTPS 传输。我很怀念。你们两个都是 + 1。

小开

从技术角度看，除 HTTPS 外，IMO 没有其他副作用。

从用户体验/用户界面的角度来看，建议使用点击通过或延迟重定向，提供视觉指示，要求人们首先输入 HTTPS URL，因为重定向本身受到 MITM 攻击。然而，没有多少 HTTPS 网站这样做，因为他们提供的视觉效果要求人们在他们的 HTTPS 页面上寻找浏览器上的锁图标。

小开

包含会话 ID cookie 的 HTTP 请求会受到会话劫持攻击。如果允许 HTTP 并重定向到 HTTPS，那么 Cookie 被标记为安全的，这一点很重要。

我也看不出为什么 HTTP 需要被完全阻止的任何技术原因，而且许多站点确实将 HTTP 转发到 HTTPS。在这样做的时候，最好实现 HTTP严格传输安全(HSTS) ，这是一种网络安全机制，它声明浏览器只能使用 HTTPS 连接。

HSTS 通过指定诸如 Strict-Transport-Security: max-age=31536000之类的响应头来实现。遵从用户代理将自动将不安全链接转换为安全链接，从而降低中间人攻击的风险。此外，如果存在证书不安全的风险，例如不能识别根权限，那么将显示错误消息，并且不显示响应。

小开

从 HTTP 到 HTTPS 实际上并不是一个好主意。例如，攻击者可以使用像 Ssl 条带这样的工具进行中间人攻击攻击。为了解决这个问题，您应该使用 HSTS 协议。所有主流浏览器都支持它(最新的 Internet Explorer 从 IE12开始支持它) ，许多顶级网站(如 Paypal、谷歌)也在使用它。

小开

我刚刚才注意到这个问题，但是我已经写了一些类似问题的答案:

我不认为从 HTTP 重定向到 HTTPS 必然是有害的，但是这应该小心地完成。重要的是，在开发阶段，您不应该依赖于这些自动重定向。它们最多只能用于自己在浏览器中键入地址的用户。

当用户期望使用 HTTPS (并且在没有任何警告的情况下验证证书)时，检查的责任也完全由用户承担。

从 HTTP 切换到 HTTPS 的实际风险是，如果您选择保留会话，那么您可以可靠地信任在切换之前完成的操作。你的网站的流程和过程应该考虑到这一点。

例如，如果您的用户浏览您的购物网站，并添加到购物车各种项目使用 HTTP 和您计划使用 HTTPS 获取支付细节，您还应该让用户确认他们的篮子内容使用 HTTPS。

此外，当从 HTTP 切换到 HTTPS 时，您可能必须重新验证用户，并放弃纯 HTTP 会话标识符(如果有的话)。否则，攻击者也可以使用这个 cookie 移动到站点的 HTTPS 部分，并可能模拟合法用户。

小开

这是一个完全可以接受的“ bootstrap”方法——301从 HTTP 重定向到 HTTPS，然后在 HTTPS 端返回一个 HTTP严格传输安全头，以便将浏览器锁定到 HTTPS。

完全阻止 HTTP 将是一个主要的可用性问题，因为当一个 URL 没有协议指示符输入时，网络浏览器将尝试 HTTP 协议，除非浏览器支持 HSTS，并且在浏览器缓存或预加载列表中找到一个 HSTS 令牌。