More and more internet providers are striving to provide their users with secure access to online content. The en­cryp­tion protocol TLS (Transport Layer Security) has been es­tab­lished for online use, but first became known under its previous name SSL (Secure Sockets Layer). While con­nec­tions to websites via HTTP (Hypertext Transfer Protocol) are usually un­en­crypt­ed, the network protocol HTTPS (“Hypertext Transfer Protocol Secure” or “Hypertext Transfer Protocol over SSL/TLS”) gives users the pos­si­bil­i­ty, thanks to SSL/TLS en­cryp­tion, to securely organize data transfer over the net.

The internet giant Google sets a good example and ex­clu­sive­ly offers its highly fre­quent­ed web services with SSL/TLS en­cryp­tion. Since August of 2014, HTTPS has also been used as a ranking factor in organic web search al­go­rithms. This sig­nif­i­cant­ly increases the relevance of SSL/TLS-supported transport en­cryp­tion for website operators. HTTPS doesn’t provide reliable pro­tec­tion in the default con­fig­u­ra­tion, though. IT experts con­stant­ly 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 en­cryp­tions. It’s only been since 2012 that a security mechanism for HTTPS con­nec­tions became available with HSTS, which prevents attacks of this kind.

Weak points of the HTTPS tech­nol­o­gy

When a website is accessed using the network protocol HTTPS and a reliable SSL/TLS cer­tifi­cate, then the encrypted transport is generally secure. But in the past, there used to be frequent attacks on cer­ti­fi­ca­tion bodies that resulted in a large number of insecure cer­tifi­cates being used. Wide­spread usage habits and general care­less­ness in dealing with encrypted con­nec­tions also offer numerous vul­ner­a­ble points for phishing and man-in-the-middle attacks.

Redi­rect­ing 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 con­nec­tion, 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 au­to­mat­i­cal­ly converts the search query to be in­ter­pret­ed 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 Even­tu­al­ly, an encrypted con­nec­tion is es­tab­lished, but the detour via the un­en­crypt­ed URL gives hackers the chance to position them­selves 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 en­cryp­tion. If the target page is a bank or online shop, then this vul­ner­a­bil­i­ty can have serious con­se­quences for users who are carrying out trans­ac­tions with money online. To il­lus­trate with an example: public WLAN spots are available in many places. People often care­less­ly use these con­nec­tions without checking who is actually providing the internet access. Hackers take advantage of this care­less­ness 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 con­nec­tion to HTTPS.

SSL stripping

Moxie Mar­lin­spike, cyberpunk and founder of Open Whisper Systems, demon­strat­ed a technique back in 2009 as part of the Black Hat safety con­fer­ence with which the usual HTTPS con­nec­tions can be leveled out using the self-developed SSL stripping. To show where HTTPS was vul­ner­a­ble, Mar­lin­spike 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 un­en­crypt­ed HTTP con­nec­tion to the user’s browser, the program com­mu­ni­cates 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 as­so­ci­at­ed with a secure con­nec­tion. The pre­req­ui­site for an attack like this is that the hacker can read the com­mu­ni­ca­tion between the browser and the server. One solution for the security problem pointed out by Mar­lin­spike was presented by the Internet En­gi­neer­ing 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 con­nec­tions from man-in-the-middle attacks and session hijacking. With the HTTPS extension, website operators can signal web browsers through optional HTTP header in­for­ma­tion 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 oblig­a­tory directive max-age and can be expanded with the optional di­rec­tives in­cludeSub­Do­mains and preload:

                Strict-Transport-Security: max-age=31536000

The directive max-age indicates for how long a website should ex­clu­sive­ly 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 di­rec­tives from the Strict-Transport-Security header field:

  • All un­en­crypt­ed links to the re­spec­tive website must be over­writ­ten with encrypted links (http:// to https://).
  • If the security of the con­nec­tion can’t be guar­an­teed (e.g. on the basis of invalid cer­tifi­cates), then it must be ter­mi­nat­ed. The user is shown an error message.

Op­tion­al­ly, HSTS data can be extended to sub­do­mains. In this case, the header field Strict-Transport-Security is sup­ple­ment­ed with the directive in­cludeSub­Do­mains. 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 sub­do­mains under the specified domain (e.g. also for blog.example.com or adserver.example.com).

                Strict-Transport-Security: max-age=31536000; in­cludeSub­Do­mains

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

                Strict-Transport-Security: max-age=31536000; in­cludeSub­Do­mains; preload

Without the preload parameter, HSTS only affects future webpage visits: If a browser knows the in­for­ma­tion in the HSTS header of a website, then future access is im­ple­ment­ed ac­cord­ing­ly. Otherwise, the security measure doesn’t work when the site is accessed for the first time. Browser de­vel­op­ers like Google and Mozilla also offer the option to enter websites into preload lists. Websites that have been reg­is­tered for pre­load­ing are ex­clu­sive­ly accessed over HTTPS. Preload lists are managed centrally by browser de­vel­op­ers and trans­mit­ted 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-ma­nip­u­lat­able HTTPS con­nec­tion, it means that in principle each initial visit is vul­ner­a­ble 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.

The­o­ret­i­cal­ly, 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 re­quire­ments that ensure the quality of the control system:

  • All websites must present a valid SSL cer­tifi­cate.
  • HTTP URLs have to be directed to HTTPS URLs of the same host.
  • All sub­do­mains (including the www subdomain) have to be available via HTTPS.
  • The HSTS header must be delivered via the basic domain with the following pa­ra­me­ters:
    • The value for max-age must be at least eight weeks (4,838,400 seconds).
    • The HSTS header must contain the directive in­cludeSub­Do­mains.
    • The HSTS header must contain the directive preload.
    • All ad­di­tion­al 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 in­struc­tions 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 Vir­tu­al­Host (vhost) in Apache ter­mi­nol­o­gy and is con­fig­ured in­de­pen­dent­ly from other domains on the server. Since HSTS is an extension for HTTPS, this security mechanism is only available for Vir­tu­al­Hosts with port number 443 – the default port for HTTPS. To force an encrypted con­nec­tion to an HTTPS site for future visits, website operators add the desired Vir­tu­al­Host to the Apache con­fig­u­ra­tion 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 Vir­tu­al­Host container together with the other di­rec­tives:

<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 con­fig­ured in this was is accessed, Apache outputs an HSTS header with the desired pa­ra­me­ters. In this example, the browser is in­struct­ed to access websites under the domain example.com including sub­do­mains ex­clu­sive­ly with SSL/TLS en­cryp­tion for the next eight weeks.

For the con­fig­u­ra­tion to be accepted Apache must be restarted.

NGINX

Under NGINX, SSL/TLS encrypted con­nec­tions can also be forced using a simple line of code:

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

The ad­just­ment is made in the con­fig­u­ra­tion of the /etc/nginx/nginx.conf file. Instead of Vir­tu­al­Hosts, NGINX uses server blocks to define di­rec­tives:

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 con­fig­u­ra­tion.

Lighttpd

To activate HSTS for Lighttpd, you need to adjust the con­fig­u­ra­tion 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 restart­ing the server.

Microsoft IIS

Unlike Apache, NGINX, and Lighttpd, Microsoft’s server Internet In­for­ma­tion Services (IIS) is con­fig­ured 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.

Go to Main Menu