Het Diginotar incident: het certificeringsmodel van het Internet moet op de schop.

September 1, 2011
6

Deze week stond de (on)veiligheid van het Internet weer ter discussie. Een Gmail gebruiker in Iran ontdekte dat er iets mis was met het veiligheidscertificaat van die dienst. Die was namelijk vals. Het bleek dat al twee maanden geleden, op 19 juli, een digitale inbraak heeft plaatsgevonden bij Diginotar, een Nederlandse certification authority (CA). Daarbij zijn verschillende valse certificaten uit naam van Diginotar aangemaakt, waaronder het in Iran gebruikte, valse, certificaat voor Gmail.

Als noodmaatregel zijn er onmiddelijk nieuwe versies van alle belangrijke browsers (Firefox, Chrome, Explorer) uitgebracht, die een groot deel van alle door Diginotar uitgegeven certificaten ongeldig maken. Maar als gevolg hiervan worden vooral Nederlandse gebruikers gedupeerd. Diginotar heeft namelijk veel certificaten voor Nederlandse websites uitgegeven, zoals bijvoorbeeld DigiD. Mensen die na de update van hun browser via DigiD willen inloggen op een website van de overheid, krijgen een melding dat de verbinding mogelijk onveilig is!

Wat is er precies aan de hand? Hoe erg is dat? Waar ligt het aan? En wat kunnen we er aan doen?

Wat is er precies aan de hand?

Om te begrijpen wat het probleem is, is enige achtergrondkennis over de werking van het Internet (helaas) noodzakelijk.

Als je met je browser een website bezoekt, worden er allerlei berichten heen en weer gestuurd tussen jou computer en de server van de website. Zo'n bericht wordt niet in één keer naar zijn bestemming gestuurd. Dat kan immers niet, want er is geen directe verbinding tussen jou computer en alle andere computers op het Internet. In plaats daarvan wordt het bericht in een aantal stappen bij de uiteindelijke bestemming afgeleverd. Vaak gaat zo'n bericht via de servers van je eigen Internet Service Provider (ISP), een landelijke exchange (bijvoorbeeld de AMS-IX in Amsterdam) en nog een aantal van dergelijke routers.

Regelmatig proberen criminelen Internet verkeer te onderscheppen, bijvoorbeeld om te frauderen met Internetbankieren. Overheden doen dit ook, om onwelgevallig Internetverkeer te blokkeren, of om te spioneren. Ze doen dit door een zogenaamde man-in-the-middle aanval op te zetten.

Voor overheden is dit relatief makkelijk. Het is voor dictatoriale regimes eenvoudig om toegang te krijgen tot de eigen landelijke Internet exchange, en daar vervolgens al het Internet verkeer dat het land in en uit gaat te tappen. Maar ook in Nederland zijn ISPs verplicht hun netwerken open te stellen voor taps van opsporingsdiensten. Criminelen moeten iets meer moeite doen. Zij hebben niet zomaar toegang tot de servers van de ISP of de Internet exchange. Maar ook voor hun is het mogelijk om, selectief, Internet verkeer om te leiden via hun computers om vervolgens de berichten daar te onderscheppen.

Om afluisteren (en veranderen) van Internetverkeer te voorkomen zou je de berichten kunnen vercijferen door encryptie te gebruiken. Zender en ontvanger spreken hiervoor een geheime encryptiesleutel af. Zonder die sleutel kan niemand het berichtenverkeer afluisteren of veranderen. Dit lijkt veilig, maar dat is het alleen als je zeker weet dat de ontvanger aan de andere kant, waarmee je een sleutel afspreekt, ook inderdaad degene is die je denkt die hij is. Voor dit alles is het SSL/TLS protocol bedacht. Je herkent websites die hiermee beveiligd zijn aan de URL, die met https begint.

SSL gebruikt certificaten om de identiteit van een website te waarborgen. Een eigenaar van de website www.realsite.com kan een certificaat hiervoor aanvragen bij een zogenaamde Certification Authority (CA). Diginotar is zo'n CA. De CA controleert (als het goed is) of de aanvrager inderdaad de eigenaar is van de website www.realsite.com, voordat hij zo'n certificaat uitgeeft. Als een gebruiker vervolgens naar de website https://www.realsite.com surft, vraagt de browser om het certificaat. De browser controleert dan of het certificaat echt is, nog geldig is, eigendom is van de website, en of de naam in de URL overeenkomt met de naam die in het certificaat staat. Browsers kunnen certificaten uitgegeven door alle CA's (zo'n 650) in de wereld controleren (direct dan wel indirect, via het certificaat van een andere CA). Stelen van zo'n certificaat heeft overigens geen zin: alleen de oorspronkelijke aanvrager van het certificaat kan aantonen dat hij de eigenaar er van is.

Wat wel kan, is proberen een eigen certificaat aan te vragen voor een website die niet van jou is. Ook als een website al geregistreerd is bij een CA, dan kun je het nog proberen bij één van de 649 andere CA's. Sommige CA's controleren zo'n aanvraag niet goed genoeg. Je kunt ook digitaal inbreken bij een CA en dan zelf een certificaat genereren voor een website naar keuze. Dat is wat er kennelijk gebeurd is bij Diginotar. Tenslotte zou je als crimineel, of overheid, zelf een CA op kunnen richten en proberen op de lijst van 650 door browsers vertrouwde CA's te komen. De Staat der Nederlanden is dat gelukt. Maar  ook Japan, Taiwan, en vele andere...

Ben je eenmaal CA, dan kun je natuurlijk voor jezelf certificaten voor alle mogelijke websites genereren. En dus weer gewoon een man-in-the-middle aanval doen en Internetverkeer naar believen afluisteren of veranderen.

Hoe erg is dit?

Dit is een ernstige zaak. De Iraanse overheid lijkt betrokken te zijn. Er zijn namelijk ook valse certificaten gevonden voor bijvoorbeeld mozilla.org (de maker van de Firefox browser) en torproject.org (makers van anonimseringssoftware TOR dat veel door dissidenten en journalisten wordt gebruikt in landen met onderdrukkende regimes). De website van mozilla.org wordt gebruikt om de laatste versie van Firefox te downloaden. Door downloaders naar een fake site te leiden kan een aangepaste versie van Firefox geinstalleerd worden, met bijvoorbeeld spy- of malware. Iran is eerder genoemd in verband met digitale inbraken bij Comodo, een grote Amerikaanse CA. Bij die aanval werden certificaten voor dezelfde domeinen buit gemaakt.

Bovendien loopt het vertrouwen in het Internet, en Diginotar (en Nederlandse overhiedswebsites) in het bijzonder, een deuk op. Bits of Freedom stelt al:

Want Diginotar beheert ook de certificaten voor overheidssites, zoals Digid. Kunnen we die nu ook niet meer vertrouwen?

Nu ligt het eerlijk gezegd wel iets subtieler dan dat. Het certificaat van DigiD zelf kun je nog wel vertrouwen. Wat je echter niet zeker weet is of er niet een ander certificaat voor digid.nl is dat in handen is van een malafide partij. Dat heeft dus niets te maken met het feit dat nou toevallig Diginotar de certificaten voor DigiD beheerd: alle websites, in heel de wereld, zijn net zo kwetsbaar als DigiD. Zie het valse Gmail certificaat dat in Iran is ontdekt.

Eigenlijk legt dit incident iets bloot wat al veel langer bekend is. De beveiliging van het Internet door middel van certificaten is niet veilig genoeg. Het feit browsers zo'n 650 CA's vertrouwen voor het uitgeven en controleren van certificaten is een probleem. Dat heeft de afgelopen jaren al tot een aantal incidenten, vergelijkbaar met Diginotar, geleid. Bovendien: hoe weten we zeker dat een CA zijn macht niet misbruikt? Voor een commerciële CA is dat misschien economische zelfmoord (alhoewel dat nog valt te bezien: ondanks het feit dat Comodo in grote verlegenheid is gebracht door de stroom aan incidenten lijkt dat ze niet geschaad te hebben). Maar als een kleine CA, die eigenlijk een dekmantel is van een overheid, dit gericht en voldoende onzichtbaar doet, kraait er wellicht geen haan naar. Nu heeft Iran een bestaande CA gehackt. Maar waarom zou ze niet een eigen CA oprichten? Als Nederland dat kan en mag...

Waar ligt dit aan?

Het fundamentele probleem is dat het certificaten model van SSL niet ontworpen is om 2 miljoen websites te beveiligen voor miljarden gebruikers wereldwijd. Het model is een klassiek statische en hiërarchische public key infrastructure (PKI), waar een aantal bezwaren aan kleven. Kort samengevat: vertrouwensrelaties zijn dynamisch, en niet hiërarchisch.

Diginotar is van de lijst van vertrouwde CAs gehaald. Maar bij een grote CA als Comodo, die bijna een kwart van alle beveiligde websites in de wereld van een certificaat heeft voorzien, kun je dat niet zomaar doen. Dat zou een kwart van het veilige Internet tot onveilig gebied verklaren. Websites hebben over het algemeen immers maar één certificaat, uitgegeven door één CA. Dat betekent ook dat een gebruiker die zo'n website bezoekt, niet zelf kan bepalen welke CA hij al dan niet vertrouwd: hij kan enkel beslissen dat ene certificaat al dan niet te accepteren. Dat is lastig voor gebruikers uit zeg China die niet zomaar blind een Amerikaanse CA willen vertrouwen...

Wat kunnen we er aan doen?

Grote vraag is dan natuurlijk: wat kunnen we hier aan doen? Helaas is het antwoord: op korte termijn erg weinig.

Schrappen in het aantal vertrouwde certification authorities lijkt een mogelijkheid. Daarmee zouden we de rotte appels kunnen verwijderen, en wellicht een bepaalde vorm van toezicht op de overblijvende CA's kunnen instellen. De vraag is echter of we een klein aantal partijen willen vertrouwen, en een monopolie positie op de markt willen geven. Een markt die overigens steeds groter wordt omdat er naar gestreefd wordt om zoveel mogelijk sites via SSL te beveiligen. Ook onduidelijk is waar toezicht belegd zou moeten worden. Wat je echter ook doet, ook met een 10 tot 50-tig tal CA's, die in de praktijk over de hele wereld verspreid zullen zijn, is het fundamentele probleem niet opgelost.

Een andere mogelijkheid is om de macht van iedere individuele CA in te perken. Het is immers toch wel vreemd dat een kleine Nederlandse CA een certificaat voor het domein van Google zou mogen uitgeven. Je zou iedere CA een scope kunnen meegeven, zeg maar een beperkte lijst van domeinen, waarbinnen de CA certificaten mag uitgeven. Diginotar zou dan bijvoorbeeld alleen certificaten voor domeinen die eindigen op .nl mogen uitgeven, en een Iraanse CA zou alleen certificaten voor domeinen die eindigen op .ir mogen uitgeven. Blijft de vraag wat we doen met internationale domeinen die eindigen op .com of .org. En bovendien: je beperkt zo hoogstens de impact van een digitale inbraak bij een CA, maar het fundamentele probleem blijft wel bestaan.

Ook DNSSEC (een veilige variant van DNS, het Domain Name System, zeg maar het telefoonboek voor het Internet) is geen oplossing. Zeker overheden hebben, zoals hierboven al beschreven, DNS niet nodig om een man-in-the-middle aanval uit te voeren.

Conclusie

Op de lange termijn zullen we moeten nadenken over een fundamenteel andere oplossing van het probleem. Een hiërarchische en statische implementatie van trust relaties werkt niet. Een dynamsich web-of-trust, zoals Pretty Good Privacy (PGP) dat ooit implementeerde, lijkt beter geschikt. Ook het idee van trust-on-first-use van Secure Shell (SSH), waarbij gebruikers de eerste keer dat ze een site bezoeken het certificaat blind accepteren en lokaal opslaan, maar vervolgens gewaarschuwd worden als het certificaat bij een volgend bezoek veranderd lijkt te zijn, lijkt in de praktijk een redelijk veiligheidsnivo te realiseren. Interessante voorbeelden die beide benaderingen proberen te integreren zijn Perspectives en Convergence. Maar ook valt niet uit te sluiten dat een geheel nieuwe, peer-to-peer architectuur voor DNS een oplossing biedt, als daarbij niet alleen de informatie, maar ook de vertouwensrelatie volledig gedistribueerd is. De privacy implicaties van zulke, meer on-line, systemen zullen nader moeten worden onderzocht. Ook is niet geheel duidelijk hoe in dit soort systemen certificaten herroepen kunnen worden.

In case you spot any errors on this page, please notify me!
Or, leave a comment.
Toon V
, 2011-09-02 09:30:48
(reply)

Of het veiligheidmodel op de schop moet komt pas in beeld als alle opties uitgeput zijn. Je zou ook aan een uitbreiding kunnen denken waarbij de hash van het certificaat gecontroleerd wordt. Je zou binnen dns(sec) hiervoor een tekstveld kunnen gebruiken wat door de client opgevraagd kan worden. Er moet dan een match zijn met de informatie in het certificaat en de informatie in dns(sec).

Jaap-Henk
, 2011-09-02 10:11:13
(reply)

Je moet dan wel de informatie uit DNS(SEC) kunnen vertrouwen. Voor DNS is dat niet het geval (DNS wordt vaak misbruikt om MITM aanvallen uit te voeren). En voor DNSSEC is dat maar de vraag. Ook daar is het trustmodel in essentie gebaseerd op een PKI, met de in het artikel al geschetste tekortkomingen.

peter ambagtsheer
, 2011-09-02 15:59:03
(reply)

Ik vraag mij af of een ‘oplossing’ is om ipv de URL, gewoon het IP adres te gebruiken. DNS vervalsing voorkom je daar mee. Of bijvoorbeeld in de hosts file een vast IP adres aan een specifiek domein te verbinden. In principe zou bij een goede netwerktopologie, een dubbel uitgevoerd IP nummer niet voor moeten komen of meteen tot een storingsmelding moeten leiden. Misschien heb je dan (nog) wat meer IP adressen nodig wereld wijd en met het dynamisch ‘spelen’ met IP adressen is dan gedaan, maar dat wisten we al: Inmiddels is IPv6 toch uitgevonden?

De consequenties van het Diginotar incident voor de consument. « Jaap-Henk Hoepman – on security, privacy and…
, 2011-09-04 17:56:06
(reply)

[…] dat er twee maanden geleden een digitale inbraak bij certicate authority (CA) Diginotar heeft plaatsgevonden. Vrijdag werd bekend dat het niet is uit te sluiten dat ook PKIOverheid certificaten (die […]

Kwetsbaarheid certificaten is niet alleen Nederlands probleem. « Jaap-Henk Hoepman – on security, privacy and…
, 2011-09-05 22:08:50
(reply)

[…] naar een fundamenteel andere oplossing voor dit probleem gezocht moeten worden (zie bijvoorbeeld deze blogpost. Advertisement LD_AddCustomAttr("AdOpt", "1"); LD_AddCustomAttr("Origin", "other"); […]

The Future of Authenticating Websites (FAWN) – 1 « Jaap-Henk Hoepman – on security, privacy and…
, 2011-10-06 20:41:05
(reply)

[…] will not elaborate on other approaches I discussed earlier (like using DNSSEC with DANE, Perspectives or […]