当我们拥有支持HSTS的浏览器时，为什么要在所有地方都使用HTTPS？

#1 楼

即使这样，即使我们浏览到一个说www.facebook.com的网站，来自Facebook服务器的响应标头也会提到HSTS


我向curl发出了http://www.facebook.com请求，这就是我得到的：

< HTTP/1.1 302 Found
< Location: https://www.facebook.com/
< Content-Type: text/html
< X-FB-Debug: zgK/A+8XSlghi/vWvAivsZ04gawpdr+3BuO7yuQaKDdrP/+B14oSVDSreHh0GbchyNPnav39pQq9Zgw5mSXX5A==
< Date: Sat, 29 Apr 2017 19:23:25 GMT
< Connection: keep-alive
< Content-Length: 0

如您所见，这里没有HSTS标头，因为根据其规范（RFC6797）：


HSTS主机不得在通过非安全传输方式传递的HTTP响应中包含STS标头字段。


Web浏览器也将在HTTP响应中忽略HSTS标头：


注意：使用HTTP访问您的站点时，浏览器将忽略Strict-Transport-Security标头。这是因为攻击者可能拦截HTTP连接并注入标头或将其删除。当通过HTTPS访问您的站点而没有证书错误时，浏览器会知道您的站点具有HTTPS功能，并将遵守Strict-Transport-Security标头。


HSTS的目的是告诉您客户端通过HTTPS访问网站后就不要切换到HTTP，反之亦然。来自Wikipedia：


HTTP严格传输安全性（HSTS）是一种Web安全策略机制，可帮助保护网站免受协议降级攻击和cookie劫持。

<协议降级攻击：


降级攻击是对计算机系统或通信协议的一种攻击形式，使其放弃高质量的操作模式（例如，加密连接） ），建议使用旧的，质量较低的操作模式（例如，纯文本），以实现与旧系统的向后兼容性。


因此，HSTS标头不用于重定向与HTTPS的新HTTP连接，但是是为了防止浏览器向现有HTTPS站点发出HTTP请求。

另一方面，HTTPS Everywhere插件可确保Web浏览器与支持HTTPS的网站建立HTTPS连接，但也可以通过HTTP进行访问。


Web上的许多网站仅对通过HTTPS加密，但是使用起来很困难。例如，它们可能默认为未加密的HTTP，或使用返回到未加密站点的链接来填充加密页面。 HTTPS Everywhere扩展通过使用巧妙的技术将对这些站点的请求重写为HTTPS来解决这些问题。

#2 楼

HSTS使用首次使用信任模型。如果您与站点的第一次连接已受到威胁，则后续请求可能不会收到HSTS错误。

HTTPS Everywhere会堵塞此漏洞，方法是让浏览器知道该站点是仅HTTPS站点。从第一个连接开始。

另外，即使某些网站支持HTTPS，也不会发布HSTS标头。或者他们的HTTPS可能位于不同的域/路径中（例如http://www.example.com但https://secure.example.com），HTTPS Everywhere试图通过重写站点的URL来帮助解决这些情况。

#3 楼

HTTPS Everywhere是客户端，而HSTS是服务器端。

因此，答案是，在服务器未设置HSTS标头的情况下，HTTPS Everywhere可以为您辩护。

#4 楼

HSTS由网站运营商酌情决定。他们必须确定强制HTTPS的安全性优势是否值得额外的服务器负载，阻止无法使用HTTPS的用户以及使缓存代理无效。强制HTTPS是HSTS的先决条件。

许多站点可选地提供HTTPS，但是通常由最终用户而不是提供链接或URL的人来选择是否使用HTTPS。
HTTPS Everywhere允许用户在此类站点上使用HTTPS，即使链接或键入的URL使用HTTP。

随着越来越多的站点将HTTPS强制并引入HSTS来降低纯文本重定向的安全风险对“ HTTPS无处不在”的需求将会减少，但是直到/除非所有提供HTTPS的站点都这样做，否则它将仍然是一个有用的插件。

#5 楼

问题在于错误的前提。


...如果我们浏览到一个说www.facebook.com的网站，则来自Facebook服务器的响应标头将提到HSTS，而我们的浏览器将将我们从http://引导到https:// ...


不是正确的*。尽管Strict-Transport-Security标头是HTTP标头，但是HSTS规范要求服务器仅将其包括在通过加密通道发送的响应中，并且要求客户端在通过非加密通道发送时忽略它。从RFC 6797开始：HTTP Strict Transport Security Host：是用于实施HSTS策略的HTTP服务器方面的合格主机。这意味着HSTS主机在通过安全传输发送的HTTP
响应消息中返回
“ Strict-Transport-Security” HTTP响应标头字段。

...

HTTP主机通过向UA发出HSTS策略来声明自己是HSTS主机，该策略由
Strict-Transport-Security HTTP响应标头字段表示并通过secure
传输（例如TLS）。

...

HSTS主机绝不能在通过非以下方式传递的HTTP响应中包含STS标头字段
安全传输。

...

如果通过不安全传输接收到HTTP响应，则UA
必须忽略任何当前的STS头字段。 br />


*好吧，我不排除Facebook的服务器和您的浏览器都违反HSTS规范的可能性。确实，配置良好且带有HSTS的服务器通常也将配置为不侦听端口80或将永久重定向发送到HTTPS URL。但是请参阅RFC的7.2节以了解其局限性。

#6 楼

我看不到关于HSTS预加载的所有答案。总结一下：现有答案中提到的警告，例如@Lie Ryan的：


HSTS使用“首次使用信任”模型。如果您与该站点的首次连接已经受到威胁，则后续请求可能不会收到HSTS错误。

（…）

另外，某些网站没有广告HSTS标头，即使它们支持HTTPS。


不适用于已预加载的网站；也就是说，它们位于网络浏览器内置的列表中。就像使用HTTPS Everywhere一样，此列表中的网站即使在第一次访问时也始终会重写为HTTPS。

因此，HTTPS Everywhere的维护者已决定不会添加预加载列表中的网站。到HTTPS Everywhere的URI数据库（可能从中删除）。

#7 楼

许多域的HSTS配置不正确。例如，Google在www.google.com及其子域上拥有HSTS，但在google.com及其子域上却没有。因此，由于访问https://google.com或https://www.google.com而没有在mail.google.com或drive.google.com上强制实施HSTS。

Google的原因具有这样的设置非常复杂。要进入Chrome HSTS预加载列表，必须具有域及其子域的HSTS。我认为Google有一些内部服务，也许是面向公众的服务，无法通过HTTPS运作。因此，针对Google.com所有子域的HSTS都会中断这些服务。所有www.google.com域的HSTS实际上仅覆盖www.google.com，因为它在* .www.google.com上没有任何子域。

但是，HTTPS Everywhere所具有的规则要比允许此类复杂用例的HSTS复杂得多。

#8 楼

我专门为Stack Exchange本身使用HTTPS Everywhere。上次我检查（几个月前）时，它没有使用HSTS，甚至没有从HTTP重定向到HTTPS。但是，它确实提供了HTTPS，因此该附件使我免于潜在的窃听。

对于Stack Exchange，情况现在可能已经改变。