HSTS

More and more internet providers are striving to provide their users with secure access to online content. The encryption protocol TLS (Transport Layer Security) has been established for online use, but first became known under its previous name SSL (Secure Sockets Layer). While connections to websites via HTTP (Hypertext Transfer Protocol) are usually unencrypted, the network protocol HTTPS (“Hypertext Transfer Protocol Secure” or “Hypertext Transfer Protocol over SSL/TLS”) gives users the possibility, thanks to SSL/TLS encryption, to securely organize data transfer over the net.

The internet giant Google sets a good example and exclusively offers its highly frequented web services with SSL/TLS encryption. Since August of 2014, HTTPS has also been used as a ranking factor in organic web search algorithms. This significantly increases the relevance of SSL/TLS-supported transport encryption for website operators. HTTPS doesn’t provide reliable protection in the default configuration, though. IT experts constantly have to be on the lookout for security gaps. The biggest dangers are man-in-the-middle attacks, which enable hackers to get around SSL/TLS encryptions. It’s only been since 2012 that a security mechanism for HTTPS connections became available with HSTS, which prevents attacks of this kind.

Weak points of the HTTPS technology

When a website is accessed using the network protocol HTTPS and a reliable SSL/TLS certificate, then the encrypted transport is generally secure. But in the past, there used to be frequent attacks on certification bodies that resulted in a large number of insecure certificates being used. Widespread usage habits and general carelessness in dealing with encrypted connections also offer numerous vulnerable points for phishing and man-in-the-middle attacks.

Redirecting HTTP to HTTPS

Internet users rarely enter URLs in their entirety. Instead, internet addresses are shortened to just their domain. The network protocol HTTPS, which should ensure the encrypted connection, is usually left out. For example, internet users will just type example.com instead of https:// example.com in the address bar of their browser, and the browser automatically converts the search query to be interpreted as the standard network protocol for web page access: HTTP.                 example.com -> http:// example.com If the target page is an encrypted website, it doesn’t occur until the server-side redirect of HTTP to HTTPS.                 http:// example.com -> https:// example.com Eventually, an encrypted connection is established, but the detour via the unencrypted URL gives hackers the chance to position themselves as a man-in-the-middle between the browser and the server. In this case, all data traffic can be read in the plaintext without the need for an attacker to crack the SSL/TLS encryption. If the target page is a bank or online shop, then this vulnerability can have serious consequences for users who are carrying out transactions with money online. To illustrate with an example: public WLAN spots are available in many places. People often carelessly use these connections without checking who is actually providing the internet access. Hackers take advantage of this carelessness by setting up their own computer as a hotspot and so recording all of the data traffic. If one of the users accesses their online banking via such a pseudo-hotspot, then the hacker is able to inject a redirect to a phishing website before the server of the online bank has the chance to reroute the HTTP connection to HTTPS.

SSL stripping

Moxie Marlinspike, cyberpunk and founder of Open Whisper Systems, demonstrated a technique back in 2009 as part of the Black Hat safety conference with which the usual HTTPS connections can be leveled out using the self-developed SSL stripping. To show where HTTPS was vulnerable, Marlinspike developed the proxy software SSLStrip. This software exploits the security gap between the rerouting of HTTP to HTTPS URLs and converts all HTTPS requests from the browser to identical HTTP requests. While SSLStrip builds an unencrypted HTTP connection to the user’s browser, the program communicates with the server at the HTTPS level. The user is fooled by the display of a lock icon in the browser bar, which usually is associated with a secure connection. The prerequisite for an attack like this is that the hacker can read the communication between the browser and the server. One solution for the security problem pointed out by Marlinspike was presented by the Internet Engineering Task Force (IETF) three years later: In 2012, the HTTPS extension HTTP Strict Transport Security (HSTS) was specified in RFC 6797.

What is HSTS?

HSTS (HTTP Strict Transport Security) is a security mechanism that was developed to protect HTTPS connections from man-in-the-middle attacks and session hijacking. With the HTTPS extension, website operators can signal web browsers through optional HTTP header information that allows a site to be retrieved in encrypted SSL/TLS encrypted form for a defined period of time. On the server side, the header field Strict-Transport-Security is used. This contains the obligatory directive max-age and can be expanded with the optional directives includeSubDomains and preload:

                Strict-Transport-Security: max-age=31536000

The directive max-age indicates for how long a website should exclusively be available in an encrypted form. This period of time is defined in seconds. A max-age of 31,536,000 seconds means a period of one year.

When an internet user visits an HSTS-secured website for the first time, the browser obtains the following directives from the Strict-Transport-Security header field:

  • All unencrypted links to the respective website must be overwritten with encrypted links (http:// to https://).
  • If the security of the connection can’t be guaranteed (e.g. on the basis of invalid certificates), then it must be terminated. The user is shown an error message.

Optionally, HSTS data can be extended to subdomains. In this case, the header field Strict-Transport-Security is supplemented with the directive includeSubDomains. This signals to the browser that the HSTS header is not only intended for the current host (e.g. www.example.com), but also for all subdomains under the specified domain (e.g. also for blog.example.com or adserver.example.com).

                Strict-Transport-Security: max-age=31536000; includeSubDomains

The directive preload allows the website to be marked for so-called preloading, and so avoid the “first visit problem”.

                Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Without the preload parameter, HSTS only affects future webpage visits: If a browser knows the information in the HSTS header of a website, then future access is implemented accordingly. Otherwise, the security measure doesn’t work when the site is accessed for the first time. Browser developers like Google and Mozilla also offer the option to enter websites into preload lists. Websites that have been registered for preloading are exclusively accessed over HTTPS. Preload lists are managed centrally by browser developers and transmitted to user browsers through updates.

Preload lists for HTTPS sites

Since HSTS only functions if a website has been called up at least once via a non-manipulatable HTTPS connection, it means that in principle each initial visit is vulnerable to SSL stripping attacks. To prevent this, all browsers today rely on lists based on an HSTS preload service provided by Google as part of the Chromium project.

Theoretically, it’s free for any website operator to enter their domain into the HSTS preload list. But the inclusion of a website is bound to basic requirements that ensure the quality of the control system:

  • All websites must present a valid SSL certificate.
  • HTTP URLs have to be directed to HTTPS URLs of the same host.
  • All subdomains (including the www subdomain) have to be available via HTTPS.
  • The HSTS header must be delivered via the basic domain with the following parameters:
    • The value for max-age must be at least eight weeks (4,838,400 seconds).
    • The HSTS header must contain the directive includeSubDomains.
    • The HSTS header must contain the directive preload.
    • All additional redirects from the HTTPS website must be contained in the HSTS header.

Among prominent users of the HSTS preload features are Google, Paypal, Twitter, and LastPass. The complete list of entered domains can be found on the Chromium project website.

HSTS setup: Short instructions for Apache2, Lighttpd, and NGINX

For HSTS to be used on the Apache HTTP server, the Apache header module (mod_headers) must first be activated. Website operators enter the following command into the terminal:

Apache HTTP Server

For HSTS to be used on the Apache HTTP server, the Apache header module (mod_headers) must first be activated. Website operators enter the following command into the terminal:

sudo a2enmod headers

If the Apache header module is activated, then you should restart the server:

sudo service apache restart

The Apache HTTP server gives you the option of running different domains on the same server. Each of these domains is referred to as a VirtualHost (vhost) in Apache terminology and is configured independently from other domains on the server. Since HSTS is an extension for HTTPS, this security mechanism is only available for VirtualHosts with port number 443 – the default port for HTTPS. To force an encrypted connection to an HTTPS site for future visits, website operators add the desired VirtualHost to the Apache configuration file https.conf at the following line of code:

Header always set Strict-Transport-Security "max-age=4838400; includeSubdomains;"

To do so, the Strict-Transport-Security header field is written to the VirtualHost container together with the other directives:

<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=4838400; includeSubdomains;"
    DocumentRoot /var/www/
</VirtualHost>

Every time a browser configured in this was is accessed, Apache outputs an HSTS header with the desired parameters. In this example, the browser is instructed to access websites under the domain example.com including subdomains exclusively with SSL/TLS encryption for the next eight weeks.

For the configuration to be accepted Apache must be restarted.

NGINX

Under NGINX, SSL/TLS encrypted connections can also be forced using a simple line of code:

add_header Strict-Transport-Security "max-age=4838400; includeSubDomains";

The adjustment is made in the configuration of the /etc/nginx/nginx.conf file. Instead of VirtualHosts, NGINX uses server blocks to define directives:

server {
    listen      443 ssl;
    server_name    example.com;
    ssl_certificate  www.example.com.crt;
    ssl_certificate_key  www.example.com.key;
    […]
    add_header Strict-Transport-Security "max-age=4838400; includeSubDomains";
}

NGINX must also be restarted after configuration.

Lighttpd

To activate HSTS for Lighttpd, you need to adjust the configuration file /etc/lighttpd/lighttpd.conf:

server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
    setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=4838400; includeSubdomains; ")
}

The settings will be accepted after restarting the server.

Microsoft IIS

Unlike Apache, NGINX, and Lighttpd, Microsoft’s server Internet Information Services (IIS) is configured over a graphic user interface. To activate HSTS, website operators take the following steps:

  • Start the IIS manager and select the desired website.
  • Select the menu item “HTTP Response Header” and click on “Add”.
  • Enter Strict-Transport-Security in the “Add Custom HTTP Response Header” dialogue box under “Name”, and under “Value” define the desired period of time (in seconds).

To finish, restart IIS.

Was this article helpful?
We use cookies on our website to provide you with the best possible user experience. By continuing to use our website or services, you agree to their use. More Information.