HSTS: zo werkt de HTTPS-uitbreiding

Verbindingen betrouwbaar beveiligen met HSTS

Steeds meer internetproviders zetten zich in om internetgebruikers een veilige toegang tot online content te bieden. Hiervoor bestaat het versleutelingsprotocol TLS (Transport Layer Security) dat al een grote bekendheid kreeg onder zijn vorige naam SSL (Secure Sockets Layer). Terwijl verbindingen met websites via HTTP (Hypertext Transfer Protocol) onversleuteld tot stand komen, biedt het netwerkprotocol HTTPS (‘Hypertext Transfer Protocol Secure’ of ‘Hypertext Transfer Protocol over SSL/TLS’) dankzij SSL/TLS-versleuteling de mogelijkheid om het dataverkeer via internet veiliger te laten verlopen.

Ook internetgigant Google geeft het goede voorbeeld en biedt zijn veelbezochte webservices uitsluitend aan met SSL/TLS-versleuteling. Sinds augustus 2014 wordt HTTPS bovendien gewaardeerd als rankingfactor in de algoritmes van de organische zoekresultaten. Dit heeft de relevantie van een SSL/TLS-ondersteunde transportversleuteling voor websitebeheerders aanmerkelijk vergroot. HTTPS biedt in de standaardconfiguratie echter nog geen betrouwbare bescherming. IT-deskundigen leggen steeds opnieuw lekken in de beveiliging bloot. Met name man-in-the-middle-aanvallen, waarmee hackers de SSL/TLS-versleuteling kunnen omzeilen, zijn gevaarlijk. Pas sinds 2012 is er met HSTS een beveiligingsmechanisme voor HTTPS-verbindingen beschikbaar dat dit soort aanvallen kan voorkomen.


HSTS beveiligt zwakke plekken in de HTTPS-technologie

Wanneer een website wordt bezocht via het netwerkprotocol HTTPS met een betrouwbaar SSL/TLS-certificaat, dan is deze vorm van transportversleuteling in principe veilig. In het verleden werden certificeringsinstanties regelmatig aangevallen, waardoor er veel onveilige certificaten in omloop kwamen. Bovendien bieden wijdverbreide gebruikspatronen en een onvoorzichtige omgang met versleutelde verbindingen talrijke zwakke plekken voor phishing en man-in-the-middle-aanvallen.


HSTS: Redirect van HTTP naar HTTPS

Redirect van HTTP naar HTTPS

Internetgebruikers typen URL’s zelden helemaal uit. In plaats daarvan worden internetadressen verkort tot alleen hun domein. Het netwerkprotocol HTTPS dat moet zorgen voor de versleutelde verbinding wordt daarbij weggelaten. Wanneer een internetgebruiker bijvoorbeeld in plaats van https://example.com alleen maar example.com in de adresbalk van de browser typt, vult de browser de zoekopdracht automatisch aan met het standaard netwerkprotocol voor de toegang tot websites: HTTP.

example.com -> http://example.com

Pas als de doelpagina een versleutelde website is, zal de server redirecten van HTTP naar HTTPS.

http://example.com -> https://example.com

Zo wordt uiteindelijk weliswaar een versleutelde verbinding tot stand gebracht, maar door de omweg via de onversleutelde URL hebben hackers toch de mogelijkheid om zich ongemerkt als man-in-the-middle te positioneren tussen browser en server. In dat geval kan al het dataverkeer in klare tekst worden meegelezen zonder dat de aanvallers de SSL/TLS-versleuteling hoeven te kraken. Wanneer de doelpagina een bank of webshop is, kan zo’n lek in de beveiliging ingrijpende gevolgen hebben voor gebruikers die geldzaken online afwikkelen.

Dit kan worden geïllustreerd aan de hand van een voorbeeld: op veel plaatsen zijn publieke wifihotspots beschikbaar. Onvoorzichtige gebruikers maken vaak verbinding met deze hotspots zonder te controleren wie de toegang tot internet beschikbaar stelt. Hackers maken gebruik van deze onoplettendheid door hun eigen computer zich te laten voordoen als hotspot en al het dataverkeer te kopiëren. Wanneer een gebruiker uit gemakzucht via zo’n pseudo-hotspot onversleuteld gaat online bankieren, kan de hacker een redirect naar een phishing-website plaatsen voordat de server van de bank de kans krijgt de HTTP-verbinding om te leiden naar HTTPS.


HSTS: SSL-Stripping

SSL-Stripping

Moxie Marlinspike, een cypherpunk en oprichter van Open Whisper Systems, demonstreerde al in 2009 in het kader van de veiligheidsconferentie Black Hat een techniek, waarmee gangbare HTTPS-verbindingen konden worden omzeild door middel van door hemzelf ontwikkelde SSL-stripping.

Om de kwetsbaarheid van HTTPS aan te tonen, ontwikkelde Marlinspike de proxy-software SSLStrip. Deze software benut het lek in de beveiliging dat bij het doorsturen van HTTP- naar HTTPS-URL’s ontstaat en zet alle HTTPS-aanvragen van de browser om in identieke HTTP-aanvragen. Terwijl SSLStrip een versleutelde HTTP-verbinding met de browser van de gebruiker maakt, communiceert het programma met de server op HTTPS-niveau. De gebruiker wordt misleid door een icoon van een slotje, als ware een veilige verbinding. Voor zo’n aanval moet de hacker de communicatie tussen browser en server mee kunnen lezen.

Een oplossing voor het veiligheidsprobleem dat Marlinspike aan de kaak stelde, werd pas drie jaar later, in 2012, gepresenteerd door de Internet Engineering Task Force (IETF). Toen werd de HTTPS-uitbreiding HTTP Strict Transport Security (HSTS) gespecificeerd in RFC 6797.


Wat is HSTS?

HSTS (HTTP Strict Transport Security) is een beveiligingsmechanisme dat is ontwikkeld om HTTPS-verbindingen te beveiligen tegen man-in-the-middle-aanvallen en session hijacking. Met de HTTPS-extensie kunnen websitebeheerders webbrowsers door optionele instellingen in de HTTP-header een melding geven dat een website gedurende een bepaalde periode uitsluitend SSL/TLS-versleuteld kan worden opgeroepen. Aan de kant van de server wordt daarvoor het headerveld Strict-Transport-Security gebruikt. Dit bevat de verplichte directive max-age en kan worden uitgebreid met de optionele directives includeSubDomains en preload:

Strict-Transport-Security: max-age=31536000

De directive max-age geeft aan hoe lang een website uitsluitend versleuteld beschikbaar moet zijn. De periode wordt gedefinieerd in secondes. Een max-age van 31.536.000 secondes is dus een periode van een jaar.

Wanneer een internetgebruiker een HSTS-beveiligde website voor het eerst bezoekt, ontvangt de browser van het headerveld Strict-Transport-Security de volgende aanwijzingen:

  • Alle onversleutelde links naar de desbetreffende website moeten worden omgeschreven in versleutelde links (http:// wordt https://).
  • Als de veiligheid van de verbinding (bijv. door een ongeldig certificaat) niet kan worden gegarandeerd, moet deze worden verbroken. De gebruiker krijgt een foutmelding te zien.

Er is een mogelijkheid om HSTS-instellingen uit te breiden met subdomeinen. In dat geval wordt het headerveld Strict-Transport-Security aangevuld met de directive includeSubDomains. Dit geeft de browser een melding dat de HSTS-header niet alleen geldt voor de actuele host (bijv. www.example.com), maar voor alle subdomeinen onder het betreffende domein (bijv. ook voor blog.example.com of adserver.example.com).

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

Met de directive preload kunnen websites worden gemarkeerd voor preloading om het “First-Visit-Problem” te voorkomen.

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

Zonder de preload-parameter heeft HSTS alleen invloed op toekomstige websitebezoeken: als een browser de informatie in de HSTS-header van een website kent, zullen toekomstige oproepen op dezelfde wijze worden behandeld. Op de eerste toegang tot een website heeft dit beveiligingsmechanisme geen effect. Browserontwikkelaars zoals Google en Mozilla bieden daarom de mogelijkheid om websites toe te voegen aan zogenaamde preloadlijsten. Websites die zijn geregistreerd voor preloading zijn uitsluitend toegankelijk via HTTPS. Preloadlijsten worden centraal beheerd door browserontwikkelaars en door middel van updates doorgegeven aan de browsers van de gebruikers.


HSTS-preloadlijst voor HTTPS-sites

Omdat HSTS alleen werkt als een website in het verleden minstens een keer via een niet te manipuleren HTTPS-verbinding is opgeroepen, is elk eerste bezoek in principe kwetsbaar voor SSL-strippingaanvallen. Om dit te voorkomen, maken alle gangbare browsers tegenwoordig gebruik van lijsten die zijn gebaseerd op een HSTS-preloadservice, beschikbaar gesteld door Google in het kader van het Chromium project. Elke websitebeheerder is in principe vrij om het eigen domein toe te voegen aan de HSTS-preloadlijst. Hier zijn echter wel basisvoorwaarden aan verbonden die de kwaliteit van het controlesysteem moeten garanderen:

  • Alle websites moeten een geldig SSL-certificaat hebben.
  • HTTP-URL’s moeten worden doorgeleid naar HTTPS-URL’s van dezelfde host.
  • Alle subdomeinen (inclusief de www-subdomeinen) moeten worden benaderd via HTTPS.
  • De HSTS-header moet via het basisdomein met de volgende parameters geleverd worden:
    • De waarde voor max-age moet minstens acht weken bedragen (4.838.400 secondes);
    • De HSTS-header moet de directive includeSubDomains bevatten;
    • De HSTS-header moet de directive preload bevatten;
    • Alle aanvullende redirects van de HTTPS-website moeten de HSTS-header bevatten.

Prominente gebruikers van de HSTS-preload feature zijn Google, PayPal, Twitter en LastPass. De volledige lijst met geregistreerde domeinen kunnen gebruikers vinden op de website van het Chromium project.


HSTS instellen: korte handleiding voor Apache2, Lighttpd en NGINX

Aanbieders van online content die hun project door middel van HSTS willen beveiligen tegen SSL-stripping moeten hun webserver overeenkomstig instellen. In de volgende korte handleiding leggen we de HSTS-configuratie uit voor Apache, NGINX, Lighttpd en Microsoft IIS.


HSTS: Apache HTTP-server

Apache HTTP-server

Om HSTS op de Apache HTTP-server te gebruiken, moet eerst de Apache headermodule (mod_headers) worden geactiveerd. Websitebeheerders voeren daarvoor het volgende commando in de terminal in:

sudo a2enmod headers

Als de Apache headermodule is geactiveerd, moet de webserver opnieuw worden opgestart:

sudo service apache restart

De Apache HTTP-server biedt de mogelijkheid om verschillende domeinen te beheren op een en dezelfde server. Elk van deze domeinen wordt in de terminologie van Apache aangeduid als VirtualHost (vhost) en onafhankelijk van andere domeinen op de server geconfigureerd. Omdat HSTS een extensie voor HTTPS is, is dit beveiligingsmechanisme alleen beschikbaar voor VirtualHosts met het poortnummer 443 – de standaardpoort voor HTTPS. Om de versleutelde verbinding met een HTTPS-website voor toekomstige bezoekers af te dwingen, voegen websitebeheerders de gewenste VirtualHost toe in het Apache configuratiebestand https.conf met de volgende coderegel:

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

Daarvoor wordt het headerveld Strict-Transport-Security samen met de andere directives in de VirtualHost container geschreven:

<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>

Telkens wanneer een browser de op deze wijze geconfigureerde website oproept, geeft Apache een HSTS-header met de gewenste parameters uit. In dit voorbeeld wordt de browser opgedragen om websites onder het domein example.com inclusief subdomeinen in de komende acht weken uitsluitend SSL/TLS-versleuteld op te roepen.

Start Apache opnieuw op, zodat de configuratie wordt opgeslagen.


HSTS: NGINX

NGINX

Ook onder NGINX kunnen SSL/TLS-versleutelde verbindingen worden afgedwongen met een simpele coderegel:

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

De aanpassing wordt uitgevoerd in het configuratiebestand /etc/nginx/nginx.conf. In plaats van VirtualHosts maakt NGINX gebruik van zogenaamde server blocks om directives te definiëren:

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";
	}

Ook NGINX moet opnieuw worden opgestart na de configuratie.


HSTS: Lighttpd

Lighttpd

Voor het activeren van HSTS voor Lighttpd voldoet een aanpassing van het configuratiebestand /etc/lighttpd/lighttpd.conf:

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

De instellingen worden opgeslagen als de webserver opnieuw wordt opgestart.


HSTS: Microsoft IIS

Microsoft IIS

Anders dan Apache, NGINX en Lighttpd wordt Internet Information Services (IIS), de webserver van Microsoft, geconfigureerd via een grafische gebruikersinterface. Om HSTS te activeren, moeten websitebeheerders de volgende stappen uitvoeren:

  • IIS-manager starten en gewenste website selecteren.
  • Menu-optie “HTTP Response Header” selecteren en op “Add” klikken.
  • In het dialoogvenster “Add Custom HTTP Response Header” onder “Name” Strict-Transport-Security invoeren en onder “Value” de gewenste periode in secondes definiëren.

Daarna moet IIS opnieuw worden opgestart.

  • Gecertificeerde veiligheid

    Gecertificeerde veiligheid
  • Beste hostingbedrijf

    Beste hostingbedrijf
  • MKB Best Choice

    MKB Best Choice
  • Professionele support

    Professionele support
  • Hosted in Germany

    Hosted in Germany