Skip to main content
TYPO3

Hosting Infrastructure typo3.com: HSTS

Author
Published
Start the Conversation
0 Comments

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 typo3.com live and stage, and various other virtual hosts, most of them below the domain typo3.com. 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 typo3.com sites in a secure manner. All sites are served via HTTPS only, common SSL check websites give typo3.com 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 typo3.com vHost looks like:

server {
    listen 80;
    listen [::]:80;
    server_name typo3.com www.typo3.com;
    return 301 https://typo3.com;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name typo3.com;
    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 typo3.com or www.typo3.com is received via IPv4 or IPv6 an immediate 301 "moved permanently" redirect to https://typo3.com is returned. There is no root directive on HTTP, just the redirect. For https://typo3.com on IPv4 or IPv6 the certificate stuff is set up and the request is served.

HSTS

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 typo3.com is affected but also all possible sub domains (more insights). It will not be possible for us to serve any site below typo3.com 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 typo3.com, 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.

Comments

No Comments

Write comment

* These fields are required