Skip to main content

Hosting Infrastructure HSTS

HTTPS only

Most of the TYPO3 GmbH web infrastructure is located on a single standard "root" server. The system has been set up from scratch based on an Ubuntu 16.04 server image. It hosts a couple of sites like the java based atlassian stack, TYPO3 instances of live and stage, and various other virtual hosts, most of them below the domain There is no container or virtual machine based setup involved.

We're in 2016, so next to modern infrastructure questions like providing Internet Protocol version 6 (IPv6), the server setup was created with as much security as feasible in mind:

  • The main web server is based on nginx handing over PHP requests to php-fpm with a single system user per vhost
  • Each vhost is separated from the others using linux access control list (ACL), reducing the impact in case of a security breach on a single vhost
  • Each vhost is HTTPS enabled

While the server internal security mechanisms like acl are an interesting topic too, we may follow-up on that with further blog posts, later.

This post is about transport security: We want our users to browse sites in a secure manner. All sites are served via HTTPS only, common SSL check websites give an "A+" rating. One simple but not too widely known mechanism to achieve that is HSTS. It basically tells your browser: "Hey, this is a HTTPS only site, remember that and never ask me via HTTP again".

Web server configuration

So, let's go a bit into nginx details. The relevant sections of the vHost looks like:

server {
    listen 80;
    listen [::]:80;
    return 301;

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/certificate.key;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    root /path/to/document/root;
    # ... more directives

That setup is straight: If an HTTP request to or is received via IPv4 or IPv6 an immediate 301 "moved permanently" redirect to is returned. There is no root directive on HTTP, just the redirect. For on IPv4 or IPv6 the certificate stuff is set up and the request is served.


The interesting directive however is "add_header Strict-Transport-Security" which adds HSTS to every HTTPS response header. In practice that directive is actually extracted to a different file called "common.conf" that is included in all vhosts.

HSTS is the abbreviation of "HTTP Strict Transport Security" and is a mechanism to help against downgrade attacks and cookie hijacking. It has been released by the Internet Engineering Task Force (IETF) as internet standard in November 2012 with RFC 6797. All modern browsers support HSTS and old browsers may just ignore that header.

If a browser receives such a header for a site it will:

  • Automatically turn any subsequent request from HTTP into HTTPS before accessing the server
  • Return an error message if the HTTPS request is not successful, maybe because of a certificate problem. No HTTP fallback is ever tried

The point is that a browser which accessed the site the first time remembers this very site as "HTTPS only" and will "never" ask for HTTP again. The problem is that lots of sites still don't support HTTPS, so the default request to a site is usually based on HTTP. HSTS turns that around which renders man-in-the-middle and session hijacking harder for an attacker.

The details of that directive say:

  • "max-age=31536000": Remember "HTTPS only" for one year
  • "includeSubDomains": If a sub domain of given domain is requested, that one is "HTTPS only" as well
  • "preload": Allow inclusion of that domain name into a static list compiled into browsers
  • "always": Instruct nginx to always add this header regardless of the response code (404, 500, whatever)

The above directive is the full take. It is hard to get rid off later again, especially since not only is affected but also all possible sub domains (more insights). It will not be possible for us to serve any site below via HTTP again - like ever. Thus, depending on needs, it might be sometimes better to leave out the "includeSubDomains" or the "preload" part to give administrators more freedom.

HSTS is a good thing to enable. In case of, we are very confident it is never required to serve content via HTTP again. It is 2016, remember?

You'll find answers to other frequently asked technical questions, instructional clips and all sorts of helpful videos on our TYPO3 YouTube channel. Come along and join us there. If you find this useful, please share the link on your network.


No Comments

Write comment

* These fields are required