https - HSTS 与仅带有安全 cookie 的 https

Question

如果我的网站使用安全会话 cookie 在 https 上提供服务并将对 http url 的任何尝试重定向到 https，它是否足够好保护？

如果不设置 HSTS 标头，我会在此设置中暴露哪些安全漏洞？

Answer 1

此策略通过使攻击者难以欺骗您的用户使用 SSL 以外的其他方式访问您的站点，从而防止被动窃听。它还可能确保用户存储的任何书签都指向 https URL，这很好。但是，HSTS 在中间人攻击的情况下仍然具有优势。

HSTS 试图解决的问题的核心是浏览器不知道给定站点是否应该使用 SSL。而且大多数用户不会先明确尝试 SSL；如果他们输入一个 URL，他们通常会首先访问非 SSL http 站点，而且通常他们只是跟随链接。如果攻击者可以诱使您的用户通过 http URL 访问您的站点，并且可以坐在用户流量的中间（例如，通过成为他们的无线 AP），那么该攻击者可以发起中间人攻击通过将用户的流量代理到您的站点并在没有 SSL 的情况下将站点呈现给用户来针对您的站点（这是一种降级攻击）。由于用户看不到 SSL，他们的浏览器不会识别出攻击者没有您网站的有效证书，并且他们 不直接连接到您的网站。（更复杂的方法是拦截 SSL 流量并为您的站点提供自签名或其他无效证书，但这通常会导致浏览器警告。）

在这种情况下，将非 SSL 用户重定向到 SSL 或在 cookie 上设置安全标志实际上对您没有多大帮助。中间人攻击者将连接到您的 SSL 站点（并将用户的操作代理到该站点），并且在将它们传递给用户时从您的 cookie 中删除安全标志。

当然，攻击者也可以删除 HSTS 标头。然而，HSTS 协议的重点在于，如果用户过去曾成功直接访问过您的网站，他们的浏览器会记住您的网站发送了 HSTS。如果他们后来连接到您的站点并发现它没有使用 SSL 或浏览器无法验证证书，浏览器将抛出错误并拒绝继续。如果浏览器支持 HSTS 并将您的站点记录为需要 SSL，这将防止攻击者将您的站点降级为非 SSL。

Wikipedia 对此进行了相当好的讨论，我认为这比RFC中的讨论更清晰。