Het belang van HTTPS

by Aaron Lenoir

Het is je misschien al opgevallen, of misschien ook niet, maar webpagina's beginnen altijd met één van de volgende twee stukjes tekst:

  • http://
  • https://

Het verschil lijkt banaal maar het is erg belangrijk. Zéker bij websites waar enig vertrouwen aan te pas komt, zoals net-banking.

2 jaar geleden had ik min of meer het verschil kunnen uitleggen, maar ondertussen leerde ik dat ik toch nog wat foute veronderstellingen maakte.

Wat is nu juist het verschil en waarom is het eigenlijk voor iedereen belangrijk?

Het Belang

Je zou durven denken dat dit een louter technische aangelegenheid is, maar niks is minder waar. Wil je je met enig vertrouwen op het internet begeven zal je toch rekening moeten houden met de vraag:

Bekijk ik deze website via HTTP of HTTPS?

Er zijn twee zaken die websites over HTTP typeren in vergelijking met websites over HTTPS:

  • Via HTTP kan alle verkeer tussen jou en de website (in twee richtingen) onderweg worden geanalyseerd, opgeslagen én gewijzigd zonder dat jij er iets van merkt
  • Via HTTP kan je niet zeker zijn dat de webpagina waarop je zit ook effectief de webpagina is waar je denkt op te zitten

Met andere woorden: zit je op een website met HTTP dan kan je die website in feite nooit vertrouwen.
Analoog aan e-mail wordt ook hier het verkeer niet beveiligd.

"Maar dat is toch al ver gezocht?", hoor ik u denken. Wel neen, dat is het niet.

Je kan bijvoorbeeld ergens ten velde met je smartphone op een WiFi netwerk connecteren. Maar vertrouw jij de eigenaar van dat netwerk wel?
Wie zegt dat de eigenaar niet:

  • alle verkeer doorheen een computer stuurt en daarbij jouw verkeer analyseert om gebruikersnamen en wachtwoorden te vinden?
    • hoe vaak gebruik je dit wachtwoord op andere websites?
  • elke webpagina die naar jou wordt gestuurd aanpast door er - bijvoorbeeld - een extra advertentie in te plaatsen?
  • elke download die je doet vervangt door een stukje spyware / malware / virus?
  • automatisch jou naar een valse website stuurt die er correct uitziet maar in handen is van corrupte individuen / organisaties
    • Bijvoorbeeld een valse website die zich voordoet als uw bank

Bovendien kan, in het geval van een onbeveiligd draadloos netwerk, ook nog eens iedereen die op datzelfde netwerk zit potentieel jouw internetverkeer afsluisteren.

De gevaren zijn zeer tastbaar. Als je je op het internet begeeft let je hier best op.

Net zo min als je de code van je bankkaart al te opzichtig ingeeft, moet je op onbetrouwbare websites vertrouwelijke gegevens gebruiken.

Beveiliging

Gelukkig is het iets eenvoudiger om je hiervoor te beschermen dan bij e-mail.
Jammer genoeg moet je grotendeels vertrouwen op de eigenaars van de websites om dit mogelijk te maken.

Websites moeten een inspanning doen om HTTPS mogelijk te maken.
Eens een website over HTTPS beschikt, en je die ook via https://... bezoekt zal:

  • het verkeer tussen jou en de website beschermd zijn voor afsluiteren én voor wijzigen ervan
  • jij zeker zijn dat de inhoud van de website effectief van die website komt (er kan dus geen "valse" website in de plaats worden gezet)

Hoe je ziet of een website al dan niet HTTPS gebruikt hangt een beetje af van de webbrowser die je gebruikt (Firefox, Chrome, Opera, IE, ...).

Er zijn drie soorten HTTPS bescherming: geen, met een standaard SSL / TLS certificaat en met een EV (Extended Validation) certificaat:

  • Geen: hier is geen certificaat in het spel en dus ook geen bescherming voor afsluisteren of aanpassen noch een garantie op de oorsprong van de website
  • Standaard Certificaat: er is een inspanning geleverd om de identiteit van de eigenaar te bevestigen, het verkeer is beveiligd voor aflsuisteren of aanpassen.
  • EV: Ook hier is het verkeer beveiligd en er is bovendien een uitgebreide validatie gebeurd van zij die het certificaat hebben aangevraagd.

Opgelet, er zijn binnen de certificaten ook vele nuances, er zijn types van certificaten die momenteel niet meer echt als veilig worden beschouwd.
Er zijn bovendien ook certificaten met of zonder "forward secrecy". Forward secrecy wil zeggen dat indien men jouw communicaties vandaag opslaat maar nog niet kan decoderen, dat men dat ook niet in de toekomst zal kunnen, zelfs niet als het certificaat in handen komt van zij die jouw gecodeerde data willen decoderen. Bij andere certificaten zouden ze die data wel kunnen decoderen.

Hieronder even een korte visuele samenvatting van hoe dit eruit ziet in de verschillende populaire webbrowsers.

Chrome

Bij chrome zal bij beveiligde verbindingen een groen slotje in de adresbalk verschijnen. Ook zal de prefix "https://" in het adres groen zijn. Bij niet beveiligde connecties verschijnt er gewoon een "document" icoontje en komt er geen groene tekst in het adres.

Website in Chrome zonder beveiliging:

{% img /images/https/Chrome-NoSecurity.png 327 628 'Chrome op een website zonder certificaat' 'Chrome zonder certificaat' %}

Website met standaard certificaat in Chrome:

{% img /images/https/Chrome-SSL.png 414 627 'Chrome op een website met SSL / TLS' 'Chrome met SSL / TLS' %}

Website met EV Certificaat in Chrome:

{% img /images/https/Chrome-EV.png 418 631 'Chrome op een website met een EV certificaat' 'Chrome met een EV certificaat' %}

Bij Chrome lijkt er dus niet meteen een visueel verschil te zijn tussen een standaard certificaat en één met Extended Validation. Bij sommige andere browsers is dit wel het geval.

Firefox

Bij onbeveiligde verbindingen verschijnt een grijze wereldbol voor het adres in de adresbalk.

Bij beveiligde verbindingen, zonder Extended Validation, verschijnt een grijs slotje in de adresbalk.

Bij beveiligde verbindingen mét Extended Validation verschijnt een groen slotje inclusief de naam van de eigenaar van het certificaat en de website.

Er zijn nog enkele andere icoontjes, zoals een grijs uitroepteken als slechts een deel van de website via een beveiligde verbinding is binnen gekomen.

Website in Firefox zonder beveiliging:

{% img /images/https/Firefox-NoSecurity.png 309 81 'Firefox op een website zonder certificaat' 'Firefox zonder certificaat' %}

Website met standaard certificaat in Firefox:

{% img /images/https/Firefox-SSL.png 259 78 'Firefox op een website met SSL / TLS' 'Firefox met SSL / TLS' %}

Website met EV Certificaat in Firefox:

{% img /images/https/Firefox-EV.png 592 78 'Firefox op een website met een EV certificaat' 'Firefox met een EV certificaat' %}

Er is bij Firefox een duidelijk visueel verschil tussen websites met en zonder Extended Validation.

Opera

Website in Opera zonder beveiliging:

{% img /images/https/Opera-NoSecurity.png 414 78 'Opera op een website zonder certificaat' 'Opera zonder certificaat' %}

Website met standaard certificaat in Opera:

{% img /images/https/Opera-SSL.png 291 74 'Opera op een website met SSL / TLS' 'Opera met SSL / TLS' %}

Website met EV Certificaat in Opera:

{% img /images/https/Opera-EV.png 476 84 'Opera op een website met een EV certificaat' 'Opera met een EV certificaat' %}

IE

Website in IE zonder beveiliging:

{% img /images/https/IE-NoSecurity.png 823 60 'IE op een website zonder certificaat' 'IE zonder certificaat' %}

Website met standaard certificaat in IE:

{% img /images/https/IE-SSL.png 862 71 'IE op een website met SSL / TLS' 'IE met SSL / TLS' %}

Website met EV Certificaat in IE:

{% img /images/https/IE-EV.png 851 63 'IE op een website met een EV certificaat' 'IE met een EV certificaat' %}

Safari

Website in Safari zonder beveiliging:

{% img /images/https/Safari-NoSecurity.png 779 90 'Safari op een website zonder certificaat' 'Safari zonder certificaat' %}

Website met standaard certificaat in Safari:

{% img /images/https/Safari-SSL.png 779 94 'Safari op een website met SSL / TLS' 'Safari met SSL / TLS' %}

Website met EV Certificaat in Safari:

{% img /images/https/Safari-EV.png 868 88 'Safari op een website met een EV certificaat' 'Safari met een EV certificaat' %}

Je kan ook zelf iets doen: als je website addressen in typt, typ dan altijd rechtstreeks "https://" vóór het adres. Dit is de meest veilige manier van werken.

Identiteit van de eigenaars

HTTPS laat je dus toe vrij zeker te zijn over de oorsprong van de webpagina's die je te zien krijgt. Stel bijvoorbeeld dat je op een malafide netwerk zit dat het adres www.mijnbank.be niet naar jouw bank laat verwijzen maar naar een valse website, dan zou je bij HTTP:// geen verschil zien, maar als je naar https://www.mijnbank.be gaat, dan kan de malafide tussenpersoon geen valse website tonen zonder dat jij daardoor foutmeldingen zult zien.

Je zal de melding krijgen dat het certificaat dat op de website wordt gebruikt niet overeenkomt met dat van "www.mijnbank.be". En het is vrij moeilijk voor malafide tussenpersonen om dit te vermijden. Niets is onfeilbaars natuurlijk, maar het is wel moeilijk.

Nuances voor ontwikkelaars

Het is één ding om als gebruiker waakzaam te zijn bij het bezoeken van websites. Voor de ontwikkelaar van websites zijn er details waar toch rekening mee moet worden gehouden. Zo gaan zij er bijvoorbeeld moeten voor zorgen dat als gebruikers op hun website moeten inloggen ze dat kunnen doen via https (anders kan men wachtwoorden afsluiteren).

Redirects

Wat je vaak ziet is dat websites, wanneer ze bezocht worden via "http://", automatisch de gebruiker naar https:// doorverwijzen. Dit kan je proberen als je bijvoorbeeld naar "http://www.google.be" zou surfen, dan kom je uiteindelijk op "https://www.google.be" terecht.

Echter, zelfs dit is in principe niet veilig. Immers, het is de webpagina, die binnen komt via http:// die gaat zeggen dat je eigenlijk op https:// moet zijn. Als er kwaad opzet in het spel is dan kan die eerste http:// pagina al worden misbruikt om de gebruiker gevaarlijke zaken door te sturen.

Het is dus eigenlijk belangrijk dat een gebruiker altijd rechtstreeks naar https:// gaat en niet via http:// gaat. Er zijn echter nog veel websites die énkel via http:// toegankelijk zijn. Daar mag je gerust even bij stil staan ...

Login Pagina's

Het was vroeger een vaak voorkomend probleem om op websites de login pagina zelf over http:// door te geven, terwijl dan het eigenlijk login gebeuren (de post) over een "beveiligde" https:// connectie ging.
Zelfs grote websites deden dit lange tijd. Gelukkig is het ondertussen algemeen bekend dat dit geen veilige strategie is. Aangezien de onbeveiligde pagina die het login formulier bevat al door een malafide persoon kan zijn onderschept en aangepast naar zijn wensen.

Sommige grote websites doen dit wel nog steeds. Ik wil geen namen noemen, maar neem als voorbeeld de belgische website van een groot credit card bedrijf met zijn roots in de US ...

Maar wat je ook vaak ziet zijn websites die een algemene website onbeveiligd (over http://) weergeven, maar waarin dan een knop naar de "login" pagina staat. Klik je op die knop kom je op een ander deel van de website waar alles mooi achter https:// zit.

Ook dat is niet veilig. Immers, de koppeling naar die login pagina kan al gewijzigd zijn door een malafide tussenpersoon.

Zonder namen te noemen, kan ik momenteel banken zien die deze techniek toepassen.

Een goed advies voor gebruikers is om de login pagina zelf, over https://, als "favoriet" te bewaren zodat je telkens rechtstreeks naar deze pagina kan gaan.

HTST Http Strict Transport Security

Een server-side redirect vanuit de server van HTTP naar HTTPS is dus niet echt betrouwbaar. Telkens als iemand naar jouw website komt via HTTP zit hij dus op een onbetrouwbare website.

Er is een manier om dit iets meer op te vangen door middel van een HTTP header die de server doorstuurt:

  • Strict-Transport-Security: "max-age=631138519"

Dit zegt de browser dat alles op deze website altijd via HTTPS moet opgevraagd worden.

De header wordt enkel meegegeven als de gebruiker reeds via HTTPS op de site zit.

Het gevolg is dat iemand één maal naar via HTTP de eerste pagina zal opvragen. De website zal dan nog steeds gewoon een redirect doen naar de HTTPS versie. Maar vanaf dan krijgt de browser de HSTS header binnen en vanaf dan kan de gebruiker niet langer op de website via HTTP. Elke request via HTTP wordt door de browser zelf al doorgestuurd naar HTTPS.

Op die manier wordt het risico op het overnemen van de redirect verlaagd.

Instellen in Apache

Bij apache kan je in de .htaccess de volgende lijn toevoegen:

Header set Strict-Transport-Security "max-age=31536000" env=HTTPS

Dit is natuurlijk in de veronderstelling dat jouw website al redirect naar HTTPS. Dit kan ook in .htaccess als volgt:

RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

Alles HTTPS

Waarom zijn dan niet alle websites enkel toegankelijk via HTTPS?

Dat is een terechte vraag waar volgens mij geen goed antwoord voor is. Het meest voorkomende argument is dat het gebruik van https een impact heeft op de snelheid van de website.

Dat klopt wel voor een deel, er zijn enkele ingewikkelde cryptografische berekeningen nodig bij elk bezoek die vermeden worden bij HTTP. Er is dus een "overhead".

En hoewel druk bezochte sites vaak bezig zijn met micro-optimalisatie is het voor minder grote sites waarschijnlijk amper een probleem om deze overhead erbij te nemen. Bovendien zien we ook dat de grootste sites ter wereld (twitter, facebook, google, wikipedia) ondertussen allemaal standaard https ondersteunen. Als zij het kunnen, dan kunnen kleinere websites (en toch zeker banken!) dat ook.

Het lijkt nog steeds een reflex te zijn van ontwikkelaars om snelheid steeds als hoogste prioriteit te nemen. Terwijl ik toch denk dat op het internet van vandaag beveiliging van de gegevens van jouw gebruikers toch als belangrijker kan worden beschouwd.

De overhead valt ook vaak nogal mee trouwens: Stackoverflow: HTTP vs HTTPS performance.

Mobile Apps / Updates

Nogal vaak worden er automatische updates voorzien in software. Alsook bij mobiele apps, waar meestal ook nog met een "back-end server" wordt gesproken door middel van programmatorische API calls, die ook via het web gaan maar onzichtbaar zijn voor de gebruiker.

Ook hier is het belangrijk dat de communicatie via https:// gaat én dat de applicaties foutmeldingen geven mocht er een probleem zijn met de certificaten. Zo kan je vermijden dat gebruikers een valse update gaan downloaden of hun gegevens gaan doorsturen naar een valse website.

Cookies

Als je website cookies gebruikt waarin gevoelige informatie zit moet je zeker een secure cookie gebruiken.

Vertrouwen

Iets om bij stil te staan is dat dit hele systeem van certificaten staat of valt met de betrouwbaarheid van de instanties die dergelijke certificaten verschaffen. Dit zijn de "Certificate Authorities", ofwel CA's.

Browsers en besturingssystemen bevatten lijsten met CA's die betrouwbaar zijn. Die lijsten zijn relatief kort, maar de grote CA's kunnen soms diensten uitbesteden aan kleine CA's en daar kan het soms iets minder betrouwbaar worden.

Geen externe partijen vertrouwen is in principe nog steeds beter - maar de infrastructuur die bij https gebruikt wordt maakt het voor eindgebruikers wel erg makkelijk te gebruiken en dat is een groot voordeel in computerbeveiliging.

PGP, de beveiliging voor e-mail verkeer, is een pak lastiger in gebruik. Het gevolg: bijna niemand gebruikt het.

SSL Labs

Wil je jouw website testen dan kan je de website SSLLabs raadplegen. Deze site geeft een overzicht van de mogelijkheden van de webserver en het certificaat met betrekking tot SSL.

Als je geen website hebt kan je er nog altijd terecht om jouw browser te testen op ondersteuning of om het één en ander bij te leren over SSL.

HTTP Shaming

Er is recent een website opgedoken die zich bezig houdt met het naar buiten brengen van websites die geen gebruik maken van https en dus een loopje nemen met de veiligheid van hun gebruikers.

De website HTTPShaming, ironisch genoeg zelf over HTTP, houdt zich hiermee bezig.

HTTPS Everwhere

Er is een add-on voor zowel Firefox, Firefox voor Android, Chrome en Opera genaamd "HTTPS Everwhere" die jou automatisch https:// zal laten gebruiken voor de websites waarvan geweten is dat ze het ondersteunen.

Conclusie

Het belang van HTTPS wordt nog vaak onderschat, getuige ervan toch enkele belangrijke websites die met financiele gegevens bezig zijn en zich toch open stellen voor mogelijke fraude van malafide tussenpersonen.

Vooral de websites zelf moeten een inspanning leveren om https mogelijk te maken. Maar ook gebruikers moeten waakzaam zijn.

Sinds de "snowden" affaire is er een groeiende interesse in het beveiligen van websites en de communicatie op het internet in het algemeen. Het credo "als je niks verkeerds doet heb je niets te verbergen" is hier natuurlijk niet van tel (het is nooit van tel), want je hebt sowieso iets te verbergen: de toegang tot jouw bankrekening bijvoorbeeld.

Gelukkig is het eenvoudiger voor eindgebruikers om zich te beschermen dan bij e-mail.

Zoals altijd hoef je ook nu niet meteen je laptop uit het raam te gooien en het internet vaarwel te zeggen. Bewust zijn van de mogelijke risico's en de gevolgen kunnen inschatten is belangrijk, verlamd raken door angst is minder waardevol.