Securing the connection to a website by using a HTTP 301 Moved Permanently response status, to notify the user’s browser to request the page by using the HTTPS protocol instead HTTP, will not prevent man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking.

The 301 redirect is considered a best practice for upgrading users from HTTP to HTTPS.


Table Of Contents
  1. Introduction
  2. Configure HSTS on Apache2
  3. Submit your domain to the preload list
  4. Be aware of the impact for this preload setting
  5. Remove a domain from the dynamic domain security policies (HSTS) in Chrome
  6. Links



Introduction

If the first connection to the website is made by using the unsecure and plain HTTP protocol, attackers could intercept the connection and redirect a client to a website they control theirselves. By using unencrypted HTTP, the webbrowser (or other HTTP complying user agents) cannot verify the webserver’s identity and the user’s won’t get warned about the malicious redirect.

By using in addition to the 301 redirect also HTTP Strict Transport Security (HSTS), you can protect connections to your website against such attacks.


HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone. HSTS is an IETF standards track protocol and is specified in RFC 6797.

The HSTS Policy is communicated by the server to the user agent via an HTTP response header field named Strict-Transport-Security. HSTS Policy specifies a period of time during which the user agent should only access the server in a secure fashion. Websites using HSTS often do not accept clear text HTTP, either by rejecting connections over HTTP or systematically redirecting users to HTTPS (though this is not required by the specification). The consequence of this is that a user-agent not capable of doing TLS will not be able to connect to the site.

The protection only applies after a user has visited the site at least once, relying on the principle of Trust on first use. The way this protection works is that a user entering or selecting a URL to the site that specifies HTTP, will automatically upgrade to HTTPS, without making an HTTP request, which prevents the HTTP man-in-the-middle attack from occurring.

Source: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security


The initial request to the website remains still unprotected from active attacks if it uses an insecure protocol such as plain HTTP.

To solve this problem with HSTS, Google Chrome, Mozilla Firefox and Internet Explorer/Microsoft Edge implementing a HSTS preload list.

The initial request remains unprotected from active attacks if it uses an insecure protocol such as plain HTTP or if the URI for the initial request was obtained over an insecure channel. The same applies to the first request after the activity period specified in the advertised HSTS Policy max-age (sites should set a period of several days or months depending on user activity and behavior). Google Chrome, Mozilla Firefox and Internet Explorer/Microsoft Edge address this limitation by implementing a “HSTS preloaded list”, which is a list that contains known sites supporting HSTS. This list is distributed with the browser so that it uses HTTPS for the initial request to the listed sites as well. As previously mentioned, these pre-loaded lists cannot scale to cover the entire Web. A potential solution might be achieved by using DNS records to declare HSTS Policy, and accessing them securely via DNSSEC, optionally with certificate fingerprints to ensure validity (which requires running a validating resolver to avoid last mile issues).

Source: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#Limitations




Configure HSTS on Apache2

To be able to configure HSTS on Apache2, we first need to enable the Apache-Header-Modul (mod_headers)

sudo a2enmod headers


For domains we want to enable HSTS we just need to add the following directive inside the virtual host file.

Header always set Strict-Transport-Security “max-age=31536000; includeSubdomains;”

max-age
The time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS

max-age is specified in seconds
max-age 31536000
is equal to one non-leap year

max-age=2592000
is equal to 30 days

includeSubdomains
In addition to HSTS deployment, a host for https://www.example.com should include a request to a resource from https://example.com to make sure that HSTS for the parent domain is set and protects the user from potential cookie injection attacks performed by a MITM that would inject a reference to the parent domain (or even http://nonexistentpeer.example.com), which the attacker then would answer.


<VirtualHost *:443>
    ServerAdmin support@example.com
    ServerName www.example.com
    SSLEngine on
    SSLCertificateFile /path/to/www.example.com.cert
    SSLCertificateKeyFile /path/to/www.example.com.key
    […]
    Header always set Strict-Transport-Security "max-age=31536000 ; includeSubdomains;"
    DocumentRoot /var/www/
</VirtualHost>


To enable the domain for HSTS preload list you have to add the directive preload

Header always set Strict-Transport-Security “max-age=31536000; includeSubdomains; preload“




Submit your domain to the preload list

To publish and check your domain in the HSTS preload list used by Google Chrome, Mozilla Firefox and Internet Explorer/Microsoft Edge, you can use the following link

https://hstspreload.org/




Be aware of the impact for this preload setting

By using the preload directive and registering your domain at hstspreload.org, you need to be aware of some risks this will bring for your domain.

If you set max-age 31536000, which is equal to one non-leap year, updates to the list may not be propagated until the original maximum age directive expires, even if you change this value later. This means clients using this list like the mentioned browsers further above, be only capable to connect to this domain and all subdomains by using HTTPS, if for what ever reason, you need to be able to provide content by using HTTP or self signed certificates, theses clients won’t be able to connect to before the max-age directive expires.

You will find under the following link some more risks to consider before using this preload directive in production.

Why is preloading HTTP Strict Transport Security risky?
https://searchsecurity.techtarget.com/answer/Why-is-preloading-HTTP-Strict-Transport-Security-risky





Remove a domain from the dynamic domain security policies (HSTS) in Chrome

You can clear the HSTS settings for a domain in Chrome by open the following link, this will only affect dynamic settings and not entries from the preload list.

chrome://net-internals/#hsts





Links

HTTP Strict Transport Security (HSTS)
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

HSTS: So funktioniert die HTTPS-Erweiterung
https://www.ionos.de/digitalguide/websites/web-entwicklung/hsts-https-verbindungen-zuverlaessig-absichern/
Bei HSTS (HTTP Strict Transport Security) handelt es sich um einen Sicherheitsmechanismus, der entwickelt wurde, um HTTPS-Verbindungen gegen Man-in-the-Middle-Angriffe und Session-Hijacking abzusichern. Mit der HTTPS-Erweiterung können Webseitenbetreiber Webbrowsern durch optionale Angaben im HTTP-Header signalisieren, dass eine Website für einen definierten Zeitraum ausschließlich SSL/TLS-verschlüsselt abgerufen werden kann

HTTP 301
https://en.wikipedia.org/wiki/HTTP_301

Use the HSTS header for secure communications across networks
https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/Use-the-HSTS-header-for-secure-communications-across-networks

Why is preloading HTTP Strict Transport Security risky?
https://searchsecurity.techtarget.com/answer/Why-is-preloading-HTTP-Strict-Transport-Security-risky

Strict-Transport-Security
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

Chromium Projects – HTTP Strict Transport Security
https://www.chromium.org/hsts

Re-Hashed: How to clear HSTS settings in Chrome and Firefox
https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/