20

Why does the RFC prohibit the server from sending HSTS to the client over HTTP?

I can see that if a HTTP client responds to that unsecure HTTP response it might cause that site to be inaccessible to the client, but I don't see any reason for the server to have a MUST in the protocol.

Rather the client MUST NOT respond to HSTS in unsecure HTTP responses is the correct approach in my mind. What am I missing?

#7.2. HTTP Request Type

If an HSTS Host receives an HTTP request message over a non-secure transport, it SHOULD send an HTTP response message containing a status code indicating a permanent redirect, such as status code 301 (Section 10.3.2 of [RFC2616]), and a Location header field value containing either the HTTP request's original Effective Request URI (see Section 9 ("Constructing an Effective Request URI")) altered as necessary to have a URI scheme of "https", or a URI generated according to local policy with a URI scheme of "https".

NOTE: The above behavior is a "SHOULD" rather than a "MUST" due to:

  • Risks in server-side non-secure-to-secure redirects [OWASP-TLSGuide].

  • Site deployment characteristics. For example, a site that incorporates third-party components may not behave correctly when doing server-side non-secure-to-secure redirects in the case of being accessed over non-secure transport but does behave correctly when accessed uniformly over secure transport. The latter is the case given an HSTS-capable UA that has already noted the site as a Known HSTS Host (by whatever means, e.g., prior interaction or UA configuration).

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

Improve this question

2 Answers 2

Reset to default
28

This client behavior is prohibited by section 8.1 of the RFC:

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

The spec prohibits severs from sending insecure HSTS directives and clients from processing insecure HSTS directives. This ensures that a faulty implementation in either a server or client is not sufficient to undermine HSTS; the failure must be present in both for the weakness to be present.

As noted in your question, HSTS over plain HTTP sounds like a great way for an attacker to implement long-term client-enforced denial of service on a service offered over HTTP. In fact, section 14.3 of RFC 6797 addresses this specifically (as well as an even more serious concern):

The rationale behind this [requirement that HSTS be served over secure connections only] is that if there is a "man in the middle" (MITM) -- whether a legitimately deployed proxy or an illegitimate entity -- it could cause various mischief (see also Appendix A ("Design Decision Notes") item 3, as well as Section 14.6 ("Bootstrap MITM Vulnerability")); for example:

  • Unauthorized notation of the host as a Known HSTS Host, potentially leading to a denial-of-service situation if the host does not uniformly offer its services over secure transport (see also Section 14.5 ("Denial of Service")).

  • Resetting the time to live for the host's designation as a Known HSTS Host by manipulating the max-age header field parameter value that is returned to the UA. If max-age is returned as zero, this will cause the host to cease being regarded as a Known HSTS Host by the UA, leading to either insecure connections to the host or possibly denial of service if the host delivers its services only over secure transport.

Since HTTP can be easily spoofed, an attacker could specify an HSTS directive to treat an HTTP-only site as an HTTPS site: the client would then demand HTTPS and the server would be unable to supply it.

More seriously, this section of the RFC indicates that an attacker who can issue HSTS directives for a host could strip the host's status as a Known HSTS Host, thereby dangerously allowing the client to issue plain HTTP requests to the host.

Improve this answer
0
7

This may be to avoid the use of this header to cause a denial of service attack.

Imagine an insecure HTTP-only website. Now imagine someone able to tamper with the HTTP headers sent by this site to add an HSTS header. According to the RFC:

  • The UA should stop trying to access the site through HTTP, and try to use HTTPS only instead.
  • If the UA is unable to establish a HTTPS connection, it should consider this to be a server-side error and should give the end user no recourse.

In other words, the end user would no longer be able to access this HTTP-only site, hence the DoS.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .