HSTS & .dev domain

- 3 minutes read - 562 words

A brief overview of HSTS protocol or why I chose the .dev domain

Quick intro

What happens when you’re back from a family weekend in a cabin in the woods with no internet?

I’d probably check my dog’s instagram account first. On the browser: instagram.com and … my browser is making a call to http://instagram.com

Exactly! I haven’t explicitly used https, so where does this leave me? Exposed to all sorts of man-in-the-middle attacks that wikipedia can list for us in a scary way - session hijacking, protocol downgrade attack, etc.

What happened under-the-hood? The website issued a redirect to the browser indicating the new location https://instagram.com/

HTTP/1.1 301 Moved Permanently
Location: https://instagram.com/
Content-Type: text/plain
Server: proxygen-bolt
Date: Sun, 09 Feb 2025 21:30:20 GMT
Connection: keep-alive
Content-Length: 0

What is HSTS?

HTTP Strict Transport Security is a policy mechanism that attempts to force clients to interact with web servers over HTTPS connection only, providing Transport Layer Security unlike HTTP alone. HSTS helps to protect websites against several attack of type man-in-the-middle. It is an IETF standard specified in RFC 6797.

Servers using the HSTS protocol usually either reject connections over HTTP or systematically redirect clients to HTTPS. As a result, a client not capable of doing TLS will not be able to connect to the site. This is done by the server providing a Strict-Transport-Security header in the HTTP response.

Re-using the above example, the server’s response is as below:

HTTP/2 301 
vary: Accept-Encoding
location: https://www.instagram.com/
strict-transport-security: max-age=31536000; preload; includeSubDomains
x-stack: www
content-type: text/html; charset="utf-8"
x-fb-debug: ...
content-length: 0
date: Sun, 09 Feb 2025 21:30:20 GMT
alt-svc: h3=":443"; ma=86400

The STS header contains 3 directives:

  1. max-age specifies the period of time during which the client should only access the server in a secure fashion - using HTTPS,
  2. includeSubDomains tells the browser that this also applies to any subdomain,
  3. preload applies the HSTS preload status,

The HSTS protocol only applies after a client has visited the website once, relying on the principle of “trust on first use”.

The problem? As shown in the introduction, the redirect happened over http which is still an attack vector. HSTS provides a feature to mitigate this risk: preload status.

About the preload directive…

Web server operators can request HSTS preload status, which adds their domain to a static list stored by browsers. This ensures HTTPS is enforced automatically, even before a user visits the site for the first time.

Web browsers like Chrome, Firefox, Edge, and Safari download and locally store a copy of the HSTS preload list, enforcing HSTS policies as needed. While the download frequency and implementation details vary between browsers, the overall process remains the same.

Browsers can provide the HSTS status of domains. Chrome’s can be visited at chrome://net-internals/#hsts instagram.com gives the following:

static_sts_domain: instagram.com
static_upgrade_mode: FORCE_HTTPS
static_sts_include_subdomains: true

dynamic_sts_domain: instagram.com
dynamic_upgrade_mode: FORCE_HTTPS
dynamic_sts_include_subdomains: false
dynamic_sts_expiry: 1825538008.794263

Where does that leave the .dev domain?

Since its launch in 2019, the .dev domain has been part of the HSTS preload list. This enforces HTTPS on all .dev websites and subdomains by default, without requiring individual HSTS registrations.

Owned by Google and intended for development use, .dev was designed with security in mind. To ensure HTTPS adoption, Google mandated HSTS for all .dev domains from the outset. Other TLDs such as .app or .page have also being configured this way.

References