Using HTTP Strict Transport Security (HSTS) with Apache2
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
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
Links
