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

【问题标题】：Is redirecting http to https a bad idea?将http重定向到https是一个坏主意吗？
【发布时间】：2011-05-20 21:36:47
【问题描述】：

我正在阅读this page，它说如果一个站点是 SSL 并且用户尝试通过常规 http 访问它，应用程序不应将用户重定向到 https。它应该只是阻止他。有人可以验证这个的有效性吗？这听起来不是一个好主意，我想知道将用户转发到 https 的真正风险是什么。看起来背后没有技术原因，只是这是教育用户的好方法。

禁用对域的 HTTP 访问，甚至不要将其重定向或链接到 SSL。只需告知用户此网站是无法通过 HTTP 访问，他们有通过 SSL 访问它。

这是针对 MITM 的最佳做法和网络钓鱼攻击。这样你的用户将被教育应用程序永远无法通过 HTTP 访问当他们遇到网络钓鱼时或 MITM 攻击他们会知道出了点问题。

保护您的最佳方式之一针对 MITM 攻击的应用程序和网络钓鱼攻击正在教育您用户。

【问题讨论】：

讽刺的是，这个网站是通过 HTTP 工作的。

标签： security ssl https

【解决方案1】：

包含会话 ID cookie 的 HTTP 请求会受到会话劫持攻击。重要的是，如果您确实允许 HTTP 并重定向到 HTTPS，那么 cookie 将被标记为安全。

我也看不出需要完全阻止 HTTP 的任何技术原因，而且许多站点确实将 HTTP 转发到 HTTPS。执行此操作时，强烈建议实施 HTTP 严格传输安全 (HSTS)，这是一种 Web 安全机制，它声明浏览器只能使用 HTTPS 连接。

HSTS 是通过指定一个响应头来实现的，例如Strict-Transport-Security: max-age=31536000。符合要求的用户代理会自动将不安全的链接转变为安全的链接，从而降低中间人攻击的风险。此外，如果存在证书不安全的风险，例如无法识别 root 权限，然后显示错误消息并且不显示响应。

【讨论】：

+1。要考虑在重定向中持续存在的会话 cookie 可被视为已受到损害。通常，网站会使原始 cookie 失效，并创建一个新的 cookie 用于 HTTPS 流量（好的网站也会启用安全 cookie 标志）。
如果您提供“安全”服务，请始终在会话 cookie 中使用“安全”标志！
Vineet - 理想情况下，网站会使原始 cookie 无效，但这仍然不够常见，即使在银行应用程序中也是如此！
虽然您可能不需要使用最近的协议增强功能（如 HTTP 严格传输安全性）完全阻止 HTTP，但由于 Moxie Marlinspikes sslstrip 等 SSL 剥离攻击，将 HTTP 转发到 HTTPS 并不安全。出于同样的原因，在 HTTP 页面上拥有 HTTPS 链接甚至都不会保存。 thoughtcrime.org/software/sslstrip
CORS 让你需要 https

【解决方案2】：

从 HTTP 转到 HTTPS 实际上不是一个好主意。例如，攻击者可以使用ssl strip 之类的工具进行中间人攻击。要解决此问题，您应该使用HSTS protocol。所有主要浏览器都支持它（Internet Explorer 是最新的采用者，从 IE12 开始支持它），并且被许多顶级网站（例如 Paypal、Google）使用。

【讨论】：

对 sslstrip 的引用绝对准确。如果客户端通过 HTTP 发起到服务器的连接，MITM 可以劫持会话，以明文形式保持客户端和攻击者之间的连接，即使攻击者在其与服务器的连接上遵循 HTTPS 重定向。服务器认为客户端是通过 HTTPS 连接的，而客户端认为站点是在 HTTP 上运行的。
但是在一个简单地拒绝 HTTP 的站点上，同样的 MITM 攻击难道不会同样有效吗？ HSTS 仅在至少一个干净的连接（无论是 HTTPS 还是未受到攻击的 HTTP）之后才有帮助。
没错。这就是为什么有些浏览器预装了应该通过 HSTS (dev.chromium.org/sts) 联系的域列表。这减轻了您描述的攻击。
关于“所有主流浏览器”，IE 不支持，虽然他们说会在 IE 12 中支持：eff.org/deeplinks/2014/02/websites-hsts
在任何情况下混合非安全和安全路径都是对最佳实践的根本违反。事实上，它被认为是军事通信系统中的重大安全漏洞。二次猜测这些事情不是实施者的任务；这正是所谓的安全系统首先被破坏的方式。在我看来，改变协议同样不是一个好主意。这不是应该引起争论的事情。授权用户应该难以使用安全系统。

【解决方案3】：

我没有看到从 HTTP 重定向到 HTTPS 的任何技术风险（除了我的答案末尾的更新中的风险）。例如，gmail 和 yahoo mail 正在这样做。您可以使用 HTTP 调试工具（如 Fiddler）进行检查，您可以清楚地看到服务器返回的 302 重定向响应。

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

我同意引用的文章，即 HTTPS 是抵御 MITM 攻击的最佳方法，但我不同意它是抵御网络钓鱼的最佳做法。用户教育确实是抵御网络钓鱼攻击的关键因素（用户必须检查他们是否从正确的域访问该站点），但绝不可以通过阻止 HTTP 重定向到 HTTPS 来进行教育。

更新 @Pedro 和 @Spolto 是对的。必须特别注意敏感 cookie（如会话或身份验证 cookie），它们确实应该被标记为安全，以便它们只能通过 HTTPS 传输。我错过了那个。为你们+1。

【讨论】：

如果应用程序没有使用激活了安全标志的 cookie，则不应进行重定向，攻击者可以在不安全的请求中捕获 cookie。

【解决方案4】：

我刚刚注意到这个问题，但我已经写了几个类似问题的答案：

我不认为从 HTTP 重定向到 HTTPS 一定是有害的，但这应该谨慎进行。重要的是，您不应依赖这些自动重定向在开发阶段出现。它们最多应该用于自己在浏览器中键入地址的用户。

用户也有责任检查他们是否使用 HTTPS（并且证书在没有警告的情况下进行验证）。

从 HTTP 切换到 HTTPS 的实际风险是，如果您选择保留会话，您可以可靠地信任切换之前所做的事情。您网站的流程和过程应考虑到这一点。

例如，如果您的用户浏览您的购物网站并使用 HTTP 将各种商品添加到购物车中，并且您计划使用 HTTPS 获取付款详细信息，您还应该让用户使用 HTTPS 确认其购物篮的内容。

此外，当从 HTTP 切换到 HTTPS 时，您可能必须重新验证用户身份并丢弃纯 HTTP 会话标识符（如果有）。否则，攻击者可能也能够使用该 cookie 移动到站点的该 HTTPS 部分，并可能冒充合法用户。

【讨论】：

【解决方案5】：

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

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

【讨论】：

【解决方案6】：

这是一种完全可以接受的“引导”方法 - 301 从 HTTP 重定向到 HTTPS，然后在 HTTPS 端返回一个 Strict-Transport-Security 标头以将浏览器锁定到 HTTPS。

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

【讨论】：