De Diginotar-hack nader uitgelegd

De hack bij Diginotar roept nog steeds erg veel vragen op. De uitleg die op diverse sites te vinden is, is vaak (zeer) technisch of juist heel algemeen van aard. In dit artikel tracht ik op een niet-technische wijze duidelijker te maken gemaakt wat nu de praktische gevolgen van de hack zijn.

In mijn [intlink id="7881" type="post"]eerste artikel over de Diginotar hack[/intlink] legde ik al kort uit hoe de verbinding met websites met behulp van certificaten beveiligd wordt. In dit artikel ga ik hier nader op in. Daarvoor moet eerst wat uitgelegd worden over de werking van internet.

Internetverkeer in pakketjes naar IP-nummer toe

Het internet bestaat uit een grote verzameling van aan elkaar gekoppelde netwerken. Iedere computer in die netwerken is te bereiken via een uniek nummer dat is toegekend aan die computer. Dat nummer wordt het IP-adres van die computer genoemd.

Bij het verzenden van gegevens over het internet, zoals de inhoud van een website, worden de data eerst in kleine pakketjes opgeknipt. Vervolgens worden die afzonderlijke pakketjes naar het IP-adres van de beoogde ontvanger verstuurd. Dat dataverkeer verloopt over al de verschillende aan elkaar gekoppelde netwerken en legt daarbij een (betrekkelijk) willekeurig pad af. Bij aankomst worden de datapakketjes weer in de goede volgorde gezet en kan de ontvanger het geheel lezen.

De mens gebruikt geen nummers, maar (domein)namen

In de dagelijkse praktijk op internet komt de gemiddelde computergebruiker helemaal geen IP-adressen tegen. Mensen onthouden domeinnamen nu eenmaal gemakkelijker dan (hele lange) numerieke reeksen. Er is dan ook een systeem bedacht dat domeinnamen omzet in de bijbehorende IP-adressen. Dat systeem wordt DNS genoemd. Wanneer u www.dirkzwagerieit.nl in uw browser intypt, kijkt uw browser in het DNS en ziet dat deze website op de computer met het IP-adres 213.136.25.226 wordt gehost. Uw computer zal vervolgens aan de computer op dit IP-adres vragen om onze website aan u te verzenden.

Verkeer over internet in de basis onversleuteld

Al het verkeer dat op deze wijze over het internet plaatsvindt is in principe niet versleuteld. Dat wil dus zeggen dat iedere beheerder van een netwerk dat onderdeel uitmaakt van het internet, kan meelezen met al het verkeer dat over zijn systemen verloopt. Dat geldt niet alleen voor het bezoeken van websites via een onbeveiligde verbinding, maar bijvoorbeeld ook voor het verzenden van e-mails, het online chatten of het downloaden van software.

Versleuteling met behulp van certificaten

Het kunnen afluisteren van het dataverkeer is uiteraard in veel gevallen geen wenselijke situatie. Vandaar dat tegenwoordig steeds meer dataverkeer versleuteld wordt voor het wordt verzonden.

Beveiligd (versleuteld) dataverkeer vindt plaats via het HTTPS-protocol (in plaats van via het normale onversleutelde HTTP-protocol). Daarbij worden certificaten gebruikt ter authentificatie en voor de versleuteling. De (uitvoerige) technische details daarover laat ik hier even achterwege. Het komt er op neer dat wanneer een computergebruiker een website opvraagt via het (beveiligde) HTTPS protocol, de server waarop de website staat gegevens uit het certificaat van die website aan de browser van de computergebruiker zendt. Op basis van die gegevens en een door de browser verzonnen willekeurig getal, wordt er vervolgens een (tijdelijke en unieke) coderingssleutel afgesproken tussen de browser en de server. Daarmee wordt het dataverkeer dus versleuteld op een wijze waarbij de sleutel alleen bij de browser van de computergebruiker en bij de server bekend is.

In het certificaat zelf staat onder meer vermeld welke certificaatverlenende instantie het certificaat heeft uitgegeven, bij welke domeinnaam het certificaat hoort en hoe lang het nog geldig is. De browser van de computergebruiker zal een foutmelding geven wanneer er problemen met het certificaat zijn. Dat betekent bijvoorbeeld dat een foutmelding volgt wanneer het certificaat voor een andere domeinnaam is uitgegeven dan voor de website die door de computergebruiker is opgevraagd of wanneer de geldigheid van het certificaat is verstreken. Ook zal een foutmelding volgen wanneer de geldigheid van het certificaat is ingetrokken (het certificaat staat op een "zwarte lijst").

Deze wijze van codering werkt alleen goed wanneer de daarvoor gebruikte certificaten van goede kwaliteit zijn. Vandaar ook dat browsers niet alle leveranciers van certificaten vertrouwen. Iedere moderne browser heeft een lijst van leveranciers van certificaten die worden vertrouwd. Tot voor kort stond Diginotar ook op deze lijsten. Ondertussen hebben bijna alle browsers Diginotar van deze lijsten verwijderd.

Het belang van de certificaatverlenende instantie

Voor de versleuteling wordt in feite dus heel erg sterk geleund op de certificaatverlenende instantie. Die instantie geeft een certificaat uit voor een specifieke domeinnaam en staat er daardoor min of meer voor in dat de beveiligde verbinding die tot stand komt, ook daadwerkelijk tot stand komt met de computer van de houder van de domeinnaam.

Van een goede leverancier van certificaten mag dan ook worden verwacht dat deze verifieert dat degene die een certificaat voor een bepaalde domeinnaam aanvraagt, ook daadwerkelijk de houder van die domeinnaam is. In de minimale variant van die controle wordt onderzocht of het mailadres van degene die het certificaat aanvraagt ook als contactadres bij de domeinnaamgegevens staat vermeld. Bij luxere type certificaten vinden meer uitgebreide controles plaats.

Verder mag worden verwacht dat een goede certificaatdienstverlener ten onrechte uitgegeven certificaten onmiddellijk intrekt, om misbruik van die certificaten te voorkomen. Het internetprotocol met daarin de afspraken over het gebruik van certificaten op internet houdt hier uitdrukkelijk rekening mee in de vorm van "zwarte lijsten". Bijna alle browsers controleren certificaten aan de hand van die zwarte lijsten op geldigheid.

Hoe hack je de versleutelde verbinding?

Het voorgaande is een (lange) aanloop naar de uitleg over de Diginotar hack.

Man in the middle aanval

De valse certificaten van Diginotar zijn (in ieder geval) gebruikt voor wat een "man-in-the-middle" aanval genoemd wordt. Dit wordt zo genoemd omdat het dataverkeer tussen de computergebruiker en de server dankzij een hack onderschept en vervolgens omgeleid wordt. Dit gaat als volgt.

Stap 1: verkeer omleiden naar verkeerde server

Allereerst wordt het DNS gehackt (het systeem dat domeinnamen in IP-adressen omzet). Dit kan op verschillende niveaus plaatsvinden: door een virus op de computer van de eindgebruiker, door in te breken op de router/modem van de eindgebruiker of door de provider van de gebruiker te hacken.

Het gevolg hiervan is dat een gebruiker die een bepaalde domeinnaam opvraagt, wordt gestuurd naar het verkeerde IP-adres. Daar ziet de computergebruiker echter niets van. De computer kan het ook niet opmerken en de gebruiker waarschuwen. Alles lijkt immers normaal: het IP-adres van een domeinnaam wordt opgevraagd en het DNS komt keurig met die gegevens op de proppen.

Risico omleiden is inherent aan onbeveiligde verbindingen

Dat probleem kan zich bij onversleutelde verbindingen op ieder moment voordoen. Dat is nu eenmaal een logisch gevolg van de wijze waarop internet is opgebouwd. Alleen wanneer u zeker weet dat u geen virus op uw computer heeft en uw provider (en diens leveranciers) ook alles op orde heeft, kunt u er op vertrouwen dat bij een onbeveiligde verbinding domeinnamen in de goede IP-adressen worden vertaald.

Bij beveiligde verbinding biedt certificaat normaalgesproken extra waarborg

Normaalgesproken biedt het systeem van beveiligde verbindingen met certificaten hiervoor een extra waarborg. Door het hacken van de DNS wordt de internetgebruiker weliswaar omgeleid naar een andere server, maar die andere server zal echter niet over het juiste beveiligingscertificaat beschikken om een beveiligde verbinding tot stand te brengen. Dat certificaat is immers uniek en uitgegeven aan de legitieme houder van de domeinnaam. De browser zal dan ook een waarschuwing geven dat de veiligheid van de verbinding niet kan worden gegarandeerd. Een verstandig computergebruiker volgt die waarschuwing op en verbreekt de verbinding.

Stap 2: installeer een vals (maar niet ingetrokken) certificaat van een betrouwbare certificaatverlener

Bij [intlink id="7881" type="post"]de Diginotar-hack die nu heeft plaatsgevonden[/intlink] is die extra waarborg van de certificaten ook verdwenen. Er zijn immers legitieme certificaten uitgegeven op naam van Diginotar, die nooit uitgegeven hadden mogen worden. Deze certificaten zijn geinstalleerd op de servers waar het gehackte dataverkeer naartoe is geleid. Diginotar heeft betreffende certificaten bovendien niet op de zwarte lijst geplaatst.

De browser van de computergebruiker die naar het verkeerde IP-adres werd gestuurd, kreeg op dat verkeerde IP-adres dus een geldig (niet-ingetrokken) certificaat gepresenteerd, (ogenschijnlijk) behorend bij de opgevraagde domeinnaam en afkomstig van een betrouwbare certificaatdienstverlener. Alle lichten konden dus op groen. Hoewel het verkeer werd omgeleid naar kwaadaardige computers, kreeg de gebruiker dus de indruk dat hij op versleutelde wijze communiceerde met de door hem beoogde website. Ten onrechte.

Ook wel andere hacks denkbaar

Overigens is dit niet het enige type hack dat denkbaar is met certificaten. Zo is ook denkbaar dat een hacker het doet voorkomen alsof een beveiligde e-mail afkomstig is van de certificaathouder of dat transacties ondertekend zijn met elektronische handtekeningen die niet legitiem zijn verstrekt. Mogelijk dat over dergelijke, of nog weer andere hacks, op een later moment meer bekend wordt.

Hoe nu verder?

De hack bij Diginotar lijkt het vertrouwen in het versturen van (gevoelige) gegevens via het internet geen goed te doen. Te meer niet nu bekend is geworden dat de hack niet op zichzelf staat. Zo bericht nu.nl dat de hacker die Diginotar gehackt zou hebben ook andere beveiligingsbedrijven gekraakt zou hebben. Dat roept de vraag op welke certificaatverleners nog wel te vertrouwen zijn.

Er moet echter niet alleen naar de certificaatdienstverleners worden gekeken. Zo is de vraag of browserfabrikanten wel voldoende zorgvuldig zijn geweest in het vertrouwen van bepaalde certificaatdienstverleners. Ook kan de vraag worden gesteld of bedrijven en instellingen die elektronisch communiceren gestimuleerd hebben of zelfs verplicht hebben gesteld, wel in voldoende mate stil hebben gestaan bij de risico's. Zeker nu in de wetenschap al jaren bekend is dat het hele systeem van online certificaten enkele serieuze ontwerpfouten kent. Het laatste woord over deze hack is ongetwijfeld nog lang niet gezegd.