HTTP Strict Transport Security

Introduction

As we’ve seen, servers can send HTTP headers to provide the client with additional metadata around the response. Besides sending the content that the client requested, servers are then allowed to specify how a particular resource should be read, cached or secured.

There’s a large spectrum of security-related headers that we should understand, as they have been implemented by browsers in order to make it harder for attackers to take advantage of vulnerabilities. The next paragraphs try to summarize each of them by explaining how they’re used, what kind of attacks they prevent, and a bit of history behind each header.

HSTS

Since late 2012, HTTPS-everywhere believers have found it easier to force a client to always use the secure version of the HTTP protocol, thanks to the HTTP Strict Transport Security. A simple Strict-Transport-Security: max-age=3600 will tell the browser that for the next hour (3600 seconds) it should not interact with the applications with insecure protocols.

When a user tries to access an application secured by HSTS through HTTP, the browser will simply refuse to go ahead, automatically converting http:// URLs to https://.

You can test this locally with the code at github.com/odino/wasec/tree/master/hsts. You will need to follow the instructions in the README (that involves installing a trusted SSL certificate for localhost on your machine, through the mkcert tool, and then try opening https://localhost:7889.

HTTPS

There are two servers in this example, an HTTPS one listening on 7889, and an HTTP one on port 7888. When you access the HTTPS server, it will always redirect you to the HTTP version, which will work since there is no HSTS policy on the HTTPS server.

If you instead add the hsts=on parameter in your URL, the browser will forcefully convert the link in the redirect to its https:// version. Since the server at 7888 is http-only, you will see a page that looks more or less like this: