Should HSTS header be sent on an error response?

Question

We need to configure our loadbalancer to send the HSTS header and we are debating whether or not to send the header on HTTP 4xx/5xx responses. Our main concern is application layer DDos attacks. We don't want to do the extra work of inserting the header in case an attacker starts targetting us with HTTP 404 or some other error response code. What is the right way to do this?

Answer 1

It would be wise to always force the HTTP Strict Transport Security (HSTS) header because the risk of not encrypting may be worse.

In this particular case it's a direct tradeoff between confidentiality and availability. For most but not all businesses confidentiality is more important.

If your business values the confidentiality more than availability then force HSTS if availability is more important then don't.

HSTS is also especially useful if your development teams are prone to poor security configurations on the servers behind the load balancer. HSTS allows an organization to enforce https which in general is a very good thing.

Note: In general there's also a hidden benefit to doing this on the load-balancer rather than at the webserver layer. If the load-balancer is responding with the HSTS header it's actually reducing some of the load off the systems behind it and reducing the round-trip page loading of the site to the https page. This reduces the load on the webserver a small amount and for some attacks this actually INCREASES the workload on the attacker.

For reference: https://www.rfc-editor.org/rfc/rfc6797

Answer 2

Short answer: It doesn't really matter. Longer answer follows.

What is HSTS anyway?

HSTS, or HTTP Strict Transport Security, is an HTTP response header that can be set for web browsers to force TLS connections. A typical header looks like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains

However, this header alone does not encrypt communications.

This header must be sent over a TLS connection before it can be effective.

TLS connections

TLS connections, or the more general HTTPS, encrypt browser-to-server communications in transit and provides integrity checking. By leveraging HSTS, it is an enhancement that tells the browser to never attempt connections to plain HTTP. This is an additive approach to ensuring communication only happens over HTTPS.

What do you mean by additive approach?

What is meant here is that the baseline is HTTPS. This is a requirement before HSTS and other means can even be considered. Most people, myself included, are not in the habit of typing in https://www.example.com, but instead type in www.example.com or just example.com and we expect the server to handle redirection from HTTP to HTTPS. This usability introduces the opportunity to modify cookies and other data before the victim is redirected from HTTP to HTTPS. HSTS attempts to resolve this by telling the browser to never go to HTTP and just go to HTTPS.

The secure flag in cookies tells the browser to not send those cookies over HTTP and instead only send them over HTTPS. This prevents attack tools like SSLStrip from getting the cookie data. HSTS adds another layer on top of the secure flag and tells the browser in addition to never sending cookies over HTTP, never send any data over HTTP.

Your recipe looks like this:

TLS: - Secure flag on cookies - HSTS

HSTS is not required for secure communication, unless your company policy requires it.

DDoS

The situation where an attacker looks for 404 or other responses isn't a big problem because the attacker can simply issue requests for pages that result in 200 response codes.

I said it doesn't really matter at the beginning of this response. The reason is that writing response headers at the LB will happen for non-404 pages anyway, so a DDoS situation that is described wouldn't be a concern of mine.