为什么RFC 6797禁止通过纯HTTP响应发送Strict-Transport-Security标头? [英] Why does RFC 6797 forbid sending of the Strict-Transport-Security header over plain HTTP responses?

问题描述

在阅读HSTS规范时，我在第7.2节，反对通过http而不是https:

When reading the spec for HSTS (Strict-Transport-Security), I see an injunction in section 7.2 against sending the header when accessed over http instead of https:

HSTS主机不得在HTTP响应中包含STS标头字段 通过非安全运输进行运输.

An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.

这是为什么?如果违反此规定会有什么风险?

Why is this? What are the risks if this is violated?

推荐答案

不确定您是否有要解决的特定问题，或者只是出于好奇的缘故，最好在

Not sure if you have a specific issue you are trying to solve, or are only asking for curiosity sake but this might be better asked on http://security.stackexchange.com

就像您一样，我看不到服务器通过HTTP发送此威胁.这真的没有道理，但是我不确定是否有诚实的风险.除了说如果您无法正确设置标头之外，也许您还没有准备好实施HSTS，因为如果配置错误，可能会很危险！

Like you I can't see the threat from the server sending this over HTTP. It doesn't really make sense, but I'm not sure if there is a risk to be honest. Except to say if you can't set up the header properly then perhaps you're not ready to implement HSTS as it can be dangerous if misconfigured!

更大的危险是，如果浏览器要处理通过HTTP接收的HSTS标头，则第8.1节明确指出它必须忽略:

The far bigger danger is if a browser was to process a HSTS header received over HTTP, which section 8.1 explicitly states it MUST ignore:

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

If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s).

此处的风险是，恶意的攻击者(或意外配置错误的标头)可能会导致仅浏览器处理不正确的纯HTTP网站(或混合站点的纯HTTP部分)脱机.这将有效地导致该用户的DoS，直到标头失效或站点实施HTTPS.

The risk here is that a malicious attacker (or an accidentally misconfigured header) could take a HTTP-only website offline (or the HTTP-only parts of a mixed site) if a browser incorrectly processed it. This would effectively cause a DoS for that user(s) until either the header expiries or the site implements HTTPS.

此外，如果浏览器确实通过HTTP而不是HTTPS接受此标头，则MITM攻击者有可能通过将标头设置为最大长度0来使标头过期.例如，如果您设置了较长的HSTS标头在 https://www.example.com 上，但攻击者能够使用includeSubDomain发布max-age = 0标头超过 http://example.com ，浏览器对它的处理不正确，那么它可以有效地删除HTTPS对您的保护www网站.

Additionally if a browser did accept this header over HTTP rather than HTTPS, it could be possible for a MITM attacker to expire the header by setting it to a max-age of 0. For example if you have a long HSTS header set on https://www.example.com but attacker was able to publish a max-age=0 header with includeSubDomain over http://example.com, and the browser incorrectly processed that, then it could effectively remove the protection HTTPS gives to your www site.

由于这些原因，客户端(即网络浏览器)正确实现此点并在通过HTTP提供服务时忽略HSTS标头，而仅通过HTTPS对其进行处理，这一点非常重要.这可能是RFC规定服务器不得通过HTTP发送此消息的另一个原因-以防万一浏览器实现了此错误，但老实说，如果发生这种情况，那么该浏览器将所有仅HTTP的网站置于风险之中，因为MITM攻击者可能会添加如上.

For these reasons it's very important that clients (i.e. webbrowsers) implement this correctly and ignore the HSTS header if served over HTTP and only process it over HTTPS. This could be another reason the RFC states servers must not send this over HTTP - just in case a browser implements this wrong but, to be honest, if that happens then that browser is putting all HTTP only websites at risk as a MITM attacker could add it as per above.

这篇关于为什么RFC 6797禁止通过纯HTTP响应发送Strict-Transport-Security标头?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！