Is Diginotar aansprakelijk voor de schade uit frauduleuze certificaten?
Auw. Iraans verkeer naar Gmail kon worden afgetapt dankzij een door Diginotar goedgekeurd certificaat, zo bleek deze week. Alle grote browsers revoceerden meteen het certificaat van Diginotar, hoewel Firefox later een uitzondering maakte voor DigiD. Na enig getreuzel kwam Diginotar-eigenaar Vasco met een verklaring dat men in juli was gehackt, waarna bleek dat in ieder geval de website al jaren kwetsbaar was. En daarna dook nieuws op dat er nog veel meer valse certificaten in omloop waren, waaronder voor anonimiteitsnetwerk Tor. Heeft Diginotar nu een probleem of niet?
Laten we eens doen of de publiciteit niet al genoeg is om het einde van Diginotar als merknaam in te luiden, en de juridische gevolgen bekijken van deze faal. De wet kent namelijk de nodige bepalingen over certificatiedienstverleners, oftewel personen of bedrijven die certificaten afgeven of andere diensten in verband met elektronische handtekeningen verleent, zoals de Telecommunicatiewet ze definieert.
Toen e-commerce een beetje populair begon te worden, ontstond behoefte aan het zetten van digitale handtekeningen. Waarom is mij volstrekt onduidelijk, handtekeningen zijn namelijk zelden tot nooit nodig in het handelsverkeer. Ja, als je een huis wilt kopen, maar dat is nu net een van de weinige dingen die je niet via een internetdienst kunt doen. Maar goed, er moesten digitale, pardon elektronische handtekeningen komen en daar moest dan een hele infrastructuur bij opgezet worden om te kunnen controleren wie die had gezet. Ik ben daar ooit op afgestudeerd maar ondertussen best wel cynisch over het nut van deze hele poppenkast. Waar is de infrastructuur voor analoge handtekeningen?
Afijn, die infrastructuur oftewel PKI is waar Diginotar een rol in speelde. De opzet van deze infrastructuur is hiërarchisch: we vertrouwen een partij met een certificaat omdat de uitgever van dat certificaat zegt dat dat klopt. En we vertrouwen die uitgever omdat ook hij een certificaat heeft waarvan de uitgever zegt dat het klopt. Enzovoorts, enzoverder tot we bij de wortel van deze hiërarchische boom zijn. (Terzijde: informatici tekenen zulke bomen met de wortel aan de bovenkant. Argh.) Diginotar heeft de positie van root CA, wat zo veel wil zeggen als dat wanneer Diginotar het zegt, het klopt. Gewoon, omdat het kanergens ophoudt. (Overigens geldt dit niet voor DigiD, daar is Diginotar ’slechts’ sub-root onder de Staat der Nederlanden.)
Vertrouwen is dus het fundament waar de dienstverlening van een certificatiedienstverleners op stoelt. Immers, een echt certificaat is op geen enkele wijze te onderscheiden van een per abuis of met kwade trouw uitgegeven certificaat. De enige controle is de elektronische handtekening die erbij staat, maar die zegt niets over de inhoud. Het certificaat waar het allemaal mee begon, vermeldde de sites van Google (*.google.com) maar was in gebruik bij een partij die niet Google was. Dat is fataal voor de goede werking van een PKI.
“Gekwalificeerde” certificaten mag je alleen uitgeven als je geregistreerd bent bij de OPTA (wat Diginotar ook keurig is). Een gekwalificeerd certificaat is een certificaat dat uitgegeven is door een geregistreerde partij die zich netjes aan de regels houdt over betrouwbaarheid, en dat aan een persoon gekoppeld is.
Aan een dienstverlener die dergelijke certificaten uitgeeft, worden zware eisen gesteld door de wet en het daarbij behorende besluit. Zo moet je ETSI TS 101 456 naleven en houdt OPTA toezicht. En de wet (art. 6:196b BW) verklaart de dienstverlener aansprakelijk voor alle schade door onjuist uitgegeven certificaten, tenzij zij kan bewijzen dat zij niet onzorgvuldig heeft gehandeld, of als het certificaat ingetrokken was voordat de schade ontstond, of als het certificaat voor een niet in het certificaat vermeld doel werd aangemerkt.
Alleen: de SSL-certificaten waar het om gaat, zijn geen gekwalificeerde certificaten. Daarmee is die bijzonder strenge aansprakelijkheidsregel niet van toepassing. En dan wordt het lastig, want dan is Diginotar juridisch gezien gewoon een club die iets zegt met een digitale handtekening eronder, en tsja, afgaan op wat mensen zeggen is geen reden om ze aansprakelijk te stellen als ze het fout hadden. Anders heb ik nog wel een leuke claim tegen Astro-TV. Voor aansprakelijkheid is meer nodig: je moet een wettelijke norm geschonden hebben (die in direct verband staat met de schade) of je moet maatschappelijk onzorgvuldig hebben gehandeld, oftewel “dit staat niet in de wet maar vinden we toch dusdanig onfatsoenlijk dat je alsnog schade moet vergoeden”.
Bij die onzorgvuldigheidsnorm wegen altijd de exacte omstandigheden van het geval zwaar. Zo zal bijvoorbeeld meewegen wat de oorzaak van de hack is waarmee deze certificaten gegenereerd konden worden. Was men nalatig in het sleutelbeheer? Of was dit een buitengewoon geavanceerde zero-day hack (à la de RSA phish) die niemand had kunnen opmerken? Heeft Diginotar na het ontdekken van de hack alles gedaan om de gevolgen tegen te gaan, of heeft ze juist zitten treuzelen?
Als blijkt dat ze te weinig hebben gedaan, dan kunnen getroffen Gmailende Iraniërs ze aansprakelijk stellen voor hun schade - alleen zal die lastig aan te tonen zijn. Maar ook andere partijen die getroffen zijn door de onjuist uitgegeven certificaten kunnen dit proberen. Zo zou een webwinkel die zijn SSL-certificaat ongeldig ziet worden omdat Mozilla of Microsoft Diginotar niet meer erkent, omzet kunnen mislopen omdat mensen niet meer durven te bestellen door de foutmeldingen die ze dan krijgen. Gemiste omzet is natuurlijk wel lastig om te onderbouwen, maar zoals uit een zaak tussen TROS Radar en een hondenfokker bleek, kan een deskundige worden opgeroepen die de boeken onderzoekt en inschat wat de omzet of winst zou zijn geweest. In de Radar-zaak werd die op een half miljoen euro geschat.
Arnoud
Tags:
Harm-Jan Wiegers | 2 september 2011 @ 9:00
Dank voor deze eerste juridische beschouwing over de zaak. Zou je nog iets meer willen ingaan op waarom betrokken certificaten geen ‘gekwalificeerde’ certificaten zijn?
hAl | 2 september 2011 @ 9:21
Mozilla ging met Firefox initieel veel verder dan het revoceren van het root certificaat van Diginotar. Zij maakten ook certificaten ongeldig waarbij Diginotar de uitgifte deed voor een andere root CA. Daardoor werden diverse certificaten van de Nederlandse overheid ongeldig in Firefox beta’s hoewel de root certificaten daarvan niet zijn ingetrokken.
Later heeft Mozilla voor de certificaten van de Nederlandse overheid die door Diginotar zijn uitgegeven weer een uitzondering gemaakt en die uitzondering in een nieuwe versie van Firefox gereleased.
hAl | 2 september 2011 @ 9:30
Wat ze claimen te hebben gedaan is de overheid informeren en Price Waterhouse Coopers inschakelen voor een audit.
Wat ze niet gedaan lijken de hebben is direct zelf een nieuwe root certificaat initieren en hun klanten informeren en uitgegeven certificaten overzetten naar die nieuwe root.
Wat ze ook niet gedaan hebben is afdoende constateren precies welke certificaten er onterecht zijn aangemaakt (ook PcW heeft dat blijkbaar niet geconstateerd in hun audit).
Arnoud Engelfriet | 2 september 2011 @ 9:38
@Harm-Jan: mijn collega Steven heeft daarover uitgebreid geblogd vanochtend.
Mark Berck | 2 september 2011 @ 9:41
Mijn ervaringen met diginotar (van 2 jaar terug) zijn ook niet geweldig. Het is een club van niet-technische mensen die zelf weinig begrijpen van de hele PKI-infra. Dat dit gebeurt is verbaast mij ook niets…
De grootste faal is wel dat de NL overheid zichzelf zo heeft verbonden aan deze club. Waarom heeft de overheid zelf geen certificateninstantie?
Wim ten Brink | 2 september 2011 @ 9:52
Digitale handtekeningen zijn in het algemeen behoorlijk handig om te garanderen dat je ook daadwerkelijk met de juiste persoon aan het communiceren bent. Zo’n 8 jaar geleden had ik last van iemand die zich als mij voordeed door waarop ik reageerde door mijn emails voortaan digitaal te ondertekenen. En iedereen hier dus van op de hoogte te brengen. Het resultaat was dat hij al snel door de mand viel en op een gegeven moment de boel erger maakte door het digitale bestandje met mijn handtekening aan zijn nep-emails toe te voegen, hopende dat iemand daar in zou trappen. Die actie heeft hem uiteindelijk zijn internet-verbinding gekost want een dergelijke poging tot fraude, hoe knullig ook, kon zijn provider niet accepteren na een klacht van mij… En daarna was het snel afgelopen met die nepperd.
Tegenwoordig gebruik ik geen digitale handtekening meer omdat Google hier al goede diensten voor verleent. En daarnaast is het lastig om een handtekening te zetten via webmail. Plus het feit dat veel mail applicaties, providers en Exchange-achtige systemen binnenkomende emails deels aanpassen zonder rekening te houden met een dergelijke digitale handtekening waardoor de handtekening meteen ongeldig wordt. Voor email is de digitale handtekening al tekort geschoten omdat email zelf niet 100% betrouwbaar is.
En ja, digitale handtekeningen in het algemeen… Heb ik beroepsmatig ook de nodige ervaringen mee. Het gaat dan om applicaties die betaal-opdrachten moesten ondertekenen en versturen naar de bank, vanuit de infrastruktuur van middelgrote tot grote bedrijven. Niet alleen moest de gebruiker in een scherm een overzicht zien van alle uitgaande betaal-opdrachten maar ook moest de gebruiker er een handtekening onder zetten. En daarna moest soms een tweede gebruiker een tweede handtekening plaatsen. Het resultaat was dan een getekend tekst-bestandje dat zo per email, FTP of andere route naar de bank kon. De klant hoeft dan niet software van de bank te gebruiken maar kan dus het gehele betalings-systeem in hun eigen ICT-oplossing opnemen en afhandelen. Voor control-freaks toch erg belangrijk!
Maar Diginotar is gewoon dom geweest doordat hun eigen beveiliging niet in orde was. In hoeverre ze daardoor voor de eventuele schade moeten opdraaien kan ik niet bepalen. Sowieso is het al lastig om die schade in Euro’s, Dollars of Yen uit te drukken, want wat is de preciese schade? Maar Diginotar zal onder hun huidige naam gewoon niet meer verder kunnen als bedrijf. Een dergelijke blunder bestempelt hen gewoon als onbetrouwbaar en plaatst hen in een vergelijkbare positie als Richard Nixon na het Watergate schandaal. Mogelijk krabbelen ze weer overeind maar de schade aan hun reputatie blijft.
Maar goed, die schade?… Tja, je moet dan mensen vinden die bereid zijn om gerechtelijke stappen te ondernemen tegen Diginotar en gezien de kosten van een dergelijke, civiele procedure denk ik dat veel mensen gewoon snel elders een certificaat kopen en Diginotar verder links laten liggen. Immers, schade claimen is de eerste stap. De schadevergoeding krijgen kost gewoon veel tijd, geld en als Diginotar failliet gaat is die moeite allemaal voor niets want de belastingdienst krijgt de eerste centen.
Aan de andere kant, als je bij Diginotar kijkt zie je dat niet al hun certificaten als onbetrouwbaar zijn bestempeld. Het gaat eigenlijk alleen om domein-specifieke certificaten om SSL verkeer mee te beveiligen. Diginotar levert nog diverse andere diensten dus ze kunnen blijven voortbestaan. Diginotar biedt ook hun getroffen klanten de mogelijkheid aan om hun certificaat kosteloos om te ruilen voor een PKIoverheid certificaat, aangezien veel browsers deze nog wel vertrouwen. (Hoe lang nog?) Ze zijn dus zelf ook aktief bezig om de schade zoveel mogelijk te beperken.
Ik verwacht dat ze -net als Nixon- deze kwestie wel te boven zullen komen. Gehavend met de nodige kleerscheuren maar ze hebben overlevingskansen. Het enige wat ze nodig hebben is dat ze het vertrouwen van hun klanten weer terugwinnen. En wat vaak gebeurt als een bedrijf negatief in het nieuws komt is dat er meer mensen opeens het bedrijf leren kennen. En dat kan mogelijk weer nieuwe klanten opleveren, want ook negatieve publiciteit kan voor klandizie zorgen…
Aansprakelijkheid Diginotar voor valse SSL-certificaten? | ISPam.nl | 2 september 2011 @ 11:13
[…] BW SSL-certificaten zijn geen zogenaamde gekwalificeerde certificaten, zoals Arnoud Engelfriet in dit artikel uitlegt, zodat de aansprakelijkheid van art. 6:196b BW niet opgaat. Dit artikel bepaalt dat een certificaat […]
Jeroen Hellingman | 2 september 2011 @ 11:28
In dit soort discussies wordt blijkbaar steeds vergeten dat het fundament niet het root-certificaat is, maar het platform (OS + browser) die de validatie van de certificaten doet, en die, in hun software bepalen welke certificaten ze wel of niet accepteren en dit bovendien van de ene op de andere dag kunnen veranderen met automatische updates. Internet Explorer kent iets van tussen de 200 en 300 vertrouwde certificaten, die on-demand worden gedownload, en waar minstens even schimmige partijen tussen zitten als de Iraanse overheid.
Als overheid hoef ik dus helemaal geen certificaten te vervalsen om toch tussen het Gmail verkeer van mijn burgers te komen. Ik zou ook een fake patch voor wat browsers kunnen uitrollen, of een Trojaanse paard kunnen maken die het voor mij open zet.
George | 2 september 2011 @ 11:55
Het probleem van “vertrouwen”, of eigenlijk kunnen vaststellen dat je met de juiste partij (website) verbonden bent, is dat dit voor gebruikers eenvoudig te zien moet zijn maar eigenlijk behoorlijk technisch is. Het ’slotje’ op de browser is zoiets eenvoudigs, maar zegt niets over de betrouwbaarheid van de site op zich en gebruikers hechten er, mede door marketing, een te grote waarde aan.
Al (vele) maanden geleden heeft Comodo, een grote uitgever van (o.m goedkope) certificaten, in zijn ‘Dragon’ browser (gebaseerd op Chromium) al _alle_ gewone certificaten bestempeld als “niet-vertrouwd”. Alleen de EV-SSL (Extended Validation) worden nog gezien als vertrouwenswaardig. Overige certificaten bieden slechts een beveiligde verbinding, waarvan je niet alleen op basis van het ’slotje’ kan stellen dat je met de juiste partij verbinden bent.
Als ik aan een niet-technisch persoon uitleg dat zo’n slotje vergelijkbaar is met het vertrouwen van een kennis van een vriend van een vriend (van een vriend, etc.), vraag ik meteen of ze mij hun portemonnee een uurtje willen meegeven in ruil voor een plakkertje van een geel slotje.
Wie wel eens bekeken heeft hoe veel vertrouwde Root CA’s er in zijn OS of browser geconfigureerd staan mag zich afvragen of hij deze dan ook allemaal vertrouwd, echt vertrouwd, of eigenlijk geen idee heeft wie al deze uitgevers zijn en op welke basis ze (ons) “vertrouwen” uitgeven.
George.
Franc | 2 september 2011 @ 12:09
Ja wat is je schade als je 15 jaar in een strafkamp moet omdat je dacht veilig via google te emailen?
Ik begrijp gewoon niet dat er nergens een lampje is gaan branden bij *.google.com
Richard | 2 september 2011 @ 12:26
@10 Waarom zou er een lampje moeten gaan branden, wildcard certificaten komen vaak genoeg voor…
Franc | 2 september 2011 @ 12:49
@11 een positief FTW! lampje
“KICKE google komt helemaal naar ons kleine kikkerlandje om bij ons zo’n super beveiligd certificaat te halen voor AL hun diensten wereldwijd”
maar waarschijnlijker een WTF? lampje
“google komt helemaal naar ons kleine kikkerlandje om een certificaat te halen voor AL hun diensten wereldwijd? klopt dat wel?”
MathFox | 2 september 2011 @ 14:25
@Franc, als de hackers die certificaten gemaakt hebben zonder logboekregels aan te maken… Of de logboekregels gewist hebben? (Gezien de problemen van de auditors om uit te vinden wat er precies getekend is, neem ik aan dat de administratie van ondertekende sleutels incompleet is.)
Het CA systeem is zo sterk als de zwakste schakel… En met zoveel competitie is het een race naar de bodem. Het is snel geld verdienen aan het plakken van een paar extra bitjes (”de handtekening”) aan een certificaat; serieus controleren van een aanvraag kost meer dan wat je aan de markt kunt vragen.
Piet | 3 september 2011 @ 13:37
Je bedoelt hun nabestaanden.
Er lijkt mij geen enkel excuus mogelijk. Het moet gewoon fysiek ONMOGELIJK zijn om via internet een certificaat te laten genereren voor willekeurige domeinen. De computer met de rootkey of hoe dat mag heten mag niet met internet in verbinding staan.
Piet | 3 september 2011 @ 14:02
@Wim:
Arnoud heeft het denk ik vooral over de schade van personen die getroffen zijn door nepcertificaten, zoals gemartelde Iraniërs etc.
Het lijkt mij dat bedrijven die Diginotar hebben betaald voor certificaten die nu waardeloos zijn geworden gewoon hun geld moeten terugkrijgen. Ik mag hopen dat hier geen civiele procedure nodig voor zal zijn. (En ja, Diginotar zullen ze zeker voortaan links laten liggen, want Diginotar heeft geen bestaansrecht meer.)
Duh? Die genereren ze nog steeds? Dan kunnen we PKIoverheid-certificaten dus sowieso niet meer vertrouwen, want we vertrouwen Diginotar niet meer.
Eerst en vooral moeten ze het vertrouwen terugwinnen van het gehele internet!!! Ik wil kunnen internetbankieren zonder bang te hoeven zijn voor een man in the middle met een door Diginotar uitgegeven nepcertificaat. Als het goed is gaat dit ze nooit lukken.
George | 3 september 2011 @ 14:07
Overheid zegt vertrouwen op in #diginotar t.a.v. PKIoverheid http://t.co/kyMYkcw via @dmstork @Schellevis
Ik verwacht dat ook het (subordinate) certificaat wordt ingetrokken, waarme (ook) alle door dignotar uitgegeven certificaten in het kader van PKIoverheid ongeldig zullen worden.
George.
Piet | 3 september 2011 @ 14:08
@Mathfox:
En nu is aangetoond dat het systeem niet werkt.
Er zal iets anders moeten komen. Of als het huidige systeem wordt gehandhaafd moeten al die root CA’s plaatsmaken voor een monopolist. (Minder kritieke sites kunnen dan zelf certificaten genereren, zolang de browser maar duidelijk het onderscheid aangeeft.)
Piet | 3 september 2011 @ 14:34
Apart, de UI van Firefox 6.0 biedt mij de mogelijkheid om vertrouwde CA’s te verwijderen, maar er wordt niets verwijderd.
Wim ten Brink | 3 september 2011 @ 14:48
@Piet
Tja, die zijn de slachtoffers, natuurlijk. Maar ja, die zie ik ook niet zo snel naar Nederland komen om hier een civiele procedure te starten tegen DigiNotar. En hun nabestaanden (in het ergste geval) zie ik ook niet snel een procedure starten tegen DigiNotar. Sowieso zal de Iraanse regering ook niet meewerken aan een onderzoek betreffende deze kwestie, want dan moeten ze toegeven gespioneerd te hebben. De Iraniers zijn dus zowat kansloos in een dergelijk proces.
Lijkt mij ook, maar daar heb je uiteindelijk niets aan! Deze bedrijven hebben nieuwe certificaten nodig die ze elders moeten bestellen en moeten daarnaast hun software aanpassen om de DigiNotar certificaten weg te gooien en de nieuwe certificaten in gebruik te nemen. De discussie gaat dan wel om de webbrowsers, die de grootste groep “slachtoffers” vormen, maar die certificaten zijn vast ook gebruikt in diverse “custom applicaties” en dan is het de vraag in hoeverre de code verwacht dat er certificaten van DigiNotar gebruikt worden. Veel bedrijven moeten nu hun (server) software controleren en onderzoeken hoe eenvoudig DigiNotar certificaten door andere certificaten vervangen kunnen worden. Dergelijk onderzoek is dusdanig kostbaar dat DigiNotar deze schade niet eens zal kunnen vergoeden.
De autit naar DigiNotar is gisteravond afgerond en de politiek heeft er al op gereageerd door DigiNotar nog even een extra dolk in de rug te steken. Of zoals Minister Donner zelf al zegt: “Doe dat (red: internetten) niet meer, doe net als ik met brieven en overschrijvingsbiljetten.”
Okay, we hebben een overheid uit het Stenen tijdperk, dat is nu wel duidelijk.
Oh, ja…
Yep, ze doen nog gewoon alsof er niets aan de hand is. Je kunt nog steeds bij hen certificaten bestellen. De site is nog steeds in de lucht en ze doen nu alsof er niets meer aan de hand is. Voor EUR 250 plus eenmalig EUR 50 administratiekosten kun je nu nog steeds een waardeloos certificaat kopen. Grappig genoeg werkt hun site niet zo lekker meer onder Google Chrome en ik heb wel een idee hoe dat kan.
Chrome versie 13.0.782.218 heeft in deze update bepaalde CA certificaten uitgeschakeld. West wel handig, die ongemerkte auto-update van Chrome. Chrome kon deze aanval overigens ook zelf detecteren doordat Chrome maar een beperkt aantal CA’s toelaat om Google-sites te benaderen. DigiNotar hoort daar niet bij dus iedereen met Chrome 13 kan veilig zijn GMail lezen.
Zal ze niet lukken. Mozilla heeft ze al levenslang verbannen. Een doorstart onder andere naam zal ook niet lukken omdat iedereen daar wel over gewaarschuwd wordt. Sowieso zullen browser-producenten nu ook extra goed opletten op de CA’s die ze wel vertrouwen en mogelijk zullen er meer verwijderd worden uit FireFox of Chrome.
Aangezien ik mij vaak met beveiliging heb bezig gehouden kan ik je vertellen dat je nooit, maar dan ook nooit, de garantie hebt dat je veilig kunt bankieren. Niet over het Internet, niet via de post, zelfs niet in een oude sok onder je matras. Er is altijd een risico.
Maar wat ik ook heb geleerd is dat de waarde van wat je te beschermen hebt de meest goede bescherming is. Deze hack is opgezet door de Iraanse regering met al haar financiele middelen en zal ook wel het een en ander hebben gekost. Zoiets is niet te doen voor iemand op een zolderkamertje. Je moet investeren in de infrastruktuur om dataverkeer om te leiden. Je hebt gedegen kennis nodig om de site van een CA te hacken en je moet weten welke CA het meest kwetsbaar is. Veel spioneren dus, veel personen omkopen en zwijggeld betalen en vooral zorgen dat je niet gepakt wordt. Iran kan daar makkelijk de nodige miljoenen Euro’s voor neerleggen en de regering daar is ook bereid om zoveel uit te geven om de locale bevolking beter te kunnen bespioneren. Mogelijk dat de FBI/CIA ook dergelijke nep-certificaten heeft, of mogelijk zelfs originele certificaten, waarmee ze al het dataverkeer kunnen afluisteren! Ze zijn daar alleen nog niet op betrapt…
Maar heeft een regering interesse in de paar duizend euro spaargeld die her en der op een spaarrekening staat? Lijkt mij niet. Ze zullen die informatie eerder gebruiken om verdachte personen mee op te sporen en op te pakken. Zo ook de Iraanse regering, die vooral benieuwd is naar personen die nieuws over Iran het land uit lekken…
Wim ten Brink | 3 september 2011 @ 14:54
@Piet #18, Firefox blokkeert die certificaten alleen, maar ze zijn standaard onderdeel van je besturings-systeem en mogelijk dat andere applicaties die certificaten wel vertrouwen. Onder Windows, druk op Windows+R of “startmenu/Run…” en voer uit: ‘certmgr.msc’ (zonder quotes.)
Dat is de Certificate Manager en daar kun je dus certificaten beheren. Ga ze niet verwijderen want bij een update kunnen ze gewoon weer teruggezet worden! Schakel ze uit, door ze te “disabelen”. Wel goed opletten want als je teveel uitschakelt kunnen bepaalde applicaties mogelijk niet meer werken. In het ergste geval mag je Windows opnieuw installeren omdat het root-certificaat van Windows uitgeschakeld werd! Weet wat je doet!
Piet | 3 september 2011 @ 15:21
@Wim:
Certificaten moeten voor zover ik begrijp sowieso om de zoveel jaar worden vervangen, dus dit zou geen onoverkomelijke problemen moeten opleveren. Wel moet het nu plots allemaal heel snel gebeuren, en dat brengt natuurlijk wel extra kosten mee. Maar bedrijven die certificaten gebruiken hebben ook een eigen verantwoordelijkheid wat dit betreft.
Laten we hopen dat andere browsers ook wat sanitychecks gaan inbouwen voor de belangrijkste sites, al is het natuurlijk maar een lapmiddel.
Precies, dus geen bestaansrecht meer. In ieder geval niet als root CA.
En wat betreft FF 6.0, die certificaten worden dus NIET geblokkeerd. Ik kan natuurlijk een update uitvoeren en dat zou moeten helpen, maar ik snap niet waarom FF mij die certificaten niet handmatig laat verwijderen. Misschien moet ik het doen met adminrechten, maar dan zou FF mij in ieder geval moeten waarschuwen dat het als normale gebruiker niet gaat lukken. Wat er nu gebeurt is dat ik Diginotar uit de lijst krijg, maar als ik opnieuw kijk staat Diginotar er weer leuk tussen.
Wim ten Brink | 3 september 2011 @ 15:33
@Piet, software moet sowieso ieder jaar (of vaker) een update krijgen dus als een certificaat verandert is dat ook hardcoded te dien in de code van de software. En geloof mij, je wilt niet weten hoeveel bedrijven een dergelijke fout maken waarbij een certificaat een onderdeel wordt van een applicatie. Je wilt daarnaast niet weten hoeveel bedrijven zelf het wiel heruitvinden en hun eigen management tools ontwikkelen voor digitale certificaten. (Obfuscatie noemen ze dat dan, want certificaten verwacht je op de standaard locatie dus een applicatie die deze op een aparte locatie bewaart doet iets onverwachts en onbekends.)
Betreffende die sanity checks, die zijn in Chrome eenvoudig te doen omdat de makers van Chrome weten welke certificaten Google gebruikt. De sanity check van Chrome is dan ook maar beperkt tot enkele Google-sites.
Verder gebruik ik geen FireFox. Ik vind FF net zo onbetrouwbaar als IE, mede omdat ze te vaak een doelwit vormen voor hackers. Chrome begint daar ook al last mee te krijgen maar weet zich wel beter staande te houden.
Chrome en Chrome OS hebben daarnaast veel apps die ze met elkaar delen en wat mooi is, alles wat ik op mijn Windows-systeem toevoeg aan plug-ins en favorieten worden automatisch doorgestuurd naar al mijn andere Chrome en Chrome OS installaties. Dat is zeer handig!
Daarnaast gebruik ik niet alleen Chrome op mijn Windows-systemen maar ook nog eens Chrome OS op een Samsung laptop. Apparaat is een beetje te duur voor de mogelijkheden die het heeft, maar ik ben graag een “early adapter”.
Pepijn | 4 september 2011 @ 19:05
Beste Arnoud,
Goede blog, dit artikel heeft wel eerdaags een update nodig, want het is veel erger dan je denkt. Inmiddels zijn er 531 certificaten gevonden, waaronder ook gekwalificeerde Koninklijke Notariele Beroepsorganisatie certificaten. Minister Donner & Diginotar lopen een paar stappen achter.
Ook G2-root certificaten trouwens.
Pepijn
Wim ten Brink | 4 september 2011 @ 21:35
@Pepijn, het gerucht gaat ook nog dat die hackers certificaten hebben uitgegeven voor andere PKI providers waaronder Thawte en VeriSign. Indien ze daar geldige certificaten voor hebben verkregen is het mogelijk dat ze ook net-certificaten namens die andere partijen hebben gemaakt, hoewel die natuurlijk omvallen op het moment dat de DigiNotar certificaten ongeldig worden verklaard. Desondanks betekent dit dat de beveiliging van het Internet op wereldwijd niveau nu aardig is beschadigd.
En als je bedenkt dat naast browsers ook nog enorm veel andere software afhankelijk is van dergelijke certificaten dan is de chaos enorm.
Maar voordat je in paniek raakt, zolang de andere providers niet ook gehacked zijn is er weinig aan de hand. Zolang iedereen maar de DigiNotar certificaten uitschakelt. Browsers en besturings-systemen doen dit al vrijwel automatisch. Maar misschien als je speciale software voor internet-bankieren gebruikt (Girotel?) dan kan je misschien nog een probleem hebben. Security.nl heeft er een artikel over maar de hoeveelheid schade door deze hack is niet in te schatten.
Nou ja, DigiNotar zal wel failliet gaan en moeder-bedrijf Vasco moet ook het nodige aan “damage control” doen om te voorkomen dat zij voor de volledige schade opdraaien.
Verdere gevolgen? Bedrijven en personen die moeite zullen hebben om hun belastingaangifte digitaal door te geven. En er zullen diverse sites en applicaties mogelijk de nodige certificaat-waarschuwingen gaan geven. Maar uiteindelijk is dit wel positief omdat mensen nu erop gewezen worden om toch voorzichtig te zijn met certificaten! Zeker als een certificaat ongeldig lijkt te zijn. Hopelijk worden mensen weer wat voorzichtiger door dit voorval.
Pepijn | 4 september 2011 @ 22:57
@Wim Het is zeer ernstig en diginotar heeft ook nog een tijd zijn mond gehouden. Het lijkt mij zeer waarschijnlijk dat hierdoor bijvoorbeeld Iraanse dissidenten daadwerkelijk in gevaar zijn.
Kijk voor de grap maar eens naar de lijst van sites http://blog.gerv.net/2011/09/diginotar-compromise/ , dit is dus nog niet eens de helft, maar als de Iraanse overheid dissidenten wil opsporen, dan zijn google, yahoo, skype, twitter, facebook, torproject toch wel de sites die je wilt hebben.
Diginotar is natuurlijk game over, maar het hele systeem is ziek, iedereen kan tegenwoordig certificate authority worden.
Tijd om deze klassieke Comodo grap van stal te halen….en ik denk dat die in de toekomst nog vaak terugkomt https://bugzilla.mozilla.org/show_bug.cgi?id=647959
George | 4 september 2011 @ 23:06
Het is niet uit te sluiten dat via een “Man in the Middle” aanval op de sites van andere CA’s gevoelige gegevens zijn gecompromiteerd. Te denken valt aan RA logins (zoals gebruikt bij de hack van Comodo in maart) of wellicht kunnen ook de private keys van systemen untfutselt zijn.
Al met al een zorgelijke ontwikkeling.
George.
André van Santvliet | 5 september 2011 @ 9:39
Wanneer het betrouwbaarheidsniveau van een SSL-certificaat niet gelijk is aan die van een gekwalificeerd certificaat dan vraag ik me af wat Logius dan bedoelt met wat ze hier schrijven ?
http://www.logius.nl/producten/toegang/pkioverheid/productinformatie/niveau-van-betrouwbaarheid/
Wim ten Brink | 5 september 2011 @ 10:22
@Pepijn, hoe ernstig het ook is of lijkt, paniek is gewoon nooit goed. Sowieso is het eigenlijk een oorlogsverklaring indien de Iraanse regering achter deze cyberaanval zit. Maar goed, wat dan nog? En ja, voor die Iraanse dissidenten is het ook enorm vervelend, want hun levens zijn in gevaar. Net zoals Wikileaks mensenlevens in gevaar bracht doordat er documenten van zijn uitgelekt zonder dat deze zijn geanonimiseerd.
Feit is wel dat er nu weer goed naar beveiliging wordt gekeken. Want SSL is natuurlijk een techniek die al enorm oud aan het worden is en die gewoon aan vervanging toe is. Iedere vorm van beveiliging is uiteindelijk te kraken, hoewel hackers zich hierbij vooral op de zwakste schakels zullen richten. Dat men tegenwoordig zo laks is geworden met de beveiliging binnen de CA’s is een goede aanwijzing dat deze bedrijfstak teveel prutsers heeft die met te weinig verstand van zaken een CA bedrijf opzetten en met weinig kosten (weinig gequalificeerd personeel) zo veel mogelijk geld proberen te verdienen.
Ik werkte 10 jaar geleden al met PKI certificaten voor het digitaal ondertekenen van betalings-opdrachten via de software waar ik aan werkte en het enige wat eigenlijk is veranderd is dat de security keys iets langer zijn geworden en de prijs van certificaten enorm is gedaald doordat er steeds meet CA’s bij kwamen die met elkaar gingen concurreren. Was dit eerst een vakgebied voor specialisten, nu is het allemaal gemeengoed geworden mede omdat de tools het zoveel makkelijker maken. Niet langer heb je specialisten nodig die minimaal EUR 5.000 bruto per maand vragen maar kun je met twee stagiaires voor dezelfde prijs al aan de slag. Het resultaat? De CA’s verzwakken en de zwakste schakels worden het slachtoffer.
Dus wat zijn de vervolgstappen? Ach, er zijn al diverse alternatieven die toegepast kunnen worden. Een nieuw alternatief zal dus tot nieuwe standaard uitgeroepen moeten worden en vervolgens kunnen Windows, Linux, OS-X, Chrome OS en de vele webbrowsers via de automatische updates overstappen op de nieuwe standaard. Dan is al snel 80 tot 90% weer veilig. Mede ook omdat steeds meet online bankieren gewoon via de webbrowser gebeurt zal alles weer snel beveiligd kunnen worden. Wel zullen de vele bedrijven die een beveiligde webserver hebben een aanpassing moeten doen aan hun webserver. (Nieuwe certificaten of keys voor het nieuwe systeem, bijvoorbeeld.) Dat is een investering die ze moeten doen maar dat zijn gewoon onkosten die bij het beheer van de infrastruktuur horen.
Wat overblijft zijn alle losse applicaties die PKI toepassen voor hun beveiliging. Gitotel is al ten ziele maar is een voorbeeld van een applicatie met eigen certificaten. (En een inbel-verbinding naar de ING!) Maar veel bedrijven zijn al bezig om dergelijke applicaties gewoon webbased te maken zodat ze de beveiliging van de webbrowser kunnen gebruiken.
En verder zullen vooral de grote bedrijven hun interne beveiliging moeten aanpassen. Daarvoor zal dan ook een risico-analyse moeten komen. Wat zijn de risico’s op dit moment? Welke gevolgen heeft de man-in-the-middle uiteindelijk voor de toepassingen die het bedrijf gebruikt? Hoeveel belangstelling heeft de vermoedelijke hacker (Iran) eigenlijk in de communicatie van het bedrijf? Heeft het bedrijf eigenlijk wel een connectie richting Iran?
Je moet verder niet vergeten dat je voor een man-in-the-middle aanval meer nodig hebt dan een vervalst certificaat! Je moet ook nog eens de internet-verbinding van je doelwit omleiden om je eigen servers! Dus wil je bezoekers van iusmensis.com omleiden naar iusmensis.ir dan moet je toegang hebben tot hun verbinding. En dat betekent dat je controle nodig hebt over de Internet Providers en/of het DNS systeem. Of je moet spam mailtjes versturen en bezoekers vragen om je nepsite te bezoeken met een neplink. Of je probeert systemen te infecteren met de nodige malware die op het systeem zelf de DNS aanpassingen doorvoeren.
Kortom, deze hack is inderdaad gevaarlijk en kan ernstige gevolgen hebben. Maar de aanval verder doorzetten vereist meer dan alleen nepcertificaten. Je moet ingrijpen in de verbindingen en je hebt servers nodig die het dataverkeer afvangen en doorgeven. Servers die mogelijk via een TraceRoute te detecteren zijn waarna de dader bepaald kan worden! Dus moet je veel moeite doen om ook dat te maskeren. En al die gegevens die je binnenkrijgt moet je ook nog eens filteren, waarbij je ook nog eens bekend moet zijn in de talen die gebruikt worden! In Iran gebruiken ze Fârsi, Dari en Tōjiki als dialecten van de Persische taal en daarnaast zullen ze ook Arabische en Engelse teksten moeten afluisteren. En omdat Nederland erbij is betrokken ook Nederlandse teksten. En mogelijk ook Duitse, Spaanse, Franse, Chinese, Italiaanse, Japanse en andere talenfilters. De hoeveelheid data die ze zo moeten afluisteren is dusdanig groot dat er toch een soort veiligheid is dankzij de grote nummers.
Vergelijk het met een haai en een enorme school vissen. Voor iedere vis is die haai enorm bedreigend, maar doordat ze met duizenden bij elkaar zwemmen en die haai er misschien 10 op kan eten is er in het algemeen nog steeds een behoorlijke veiligheid. Zelfs een kudde bultrug-walvissen is een bedreiging voor de vissen en zal wel veel meer slachtoffers maken maar desondanks is de overlevingskans groot.
(Server geeft een foutmelding: “De webserver heeft uw request geblokkeerd. Het bevat vermoedelijk code waarmee bekende PHP scripts gekraakt kunnen worden.” Het was even zoeken maar het foute woord is “TraceRoute”…)
Waar blijft Apple met een Safari Diginotar beveiligingsupdate - Projectcafe.co | 5 september 2011 @ 10:24
[…] post bespreken, maar tot die tijd is in ieder geval het stuk van Arnoud Engelfriet op het Internetrecht blog een […]
Ruud Harmsen | 5 september 2011 @ 11:10
> Of was dit een buitengewoon geavanceerde zero-day hack
> (à la de RSA phish) die niemand had kunnen opmerken?
Raar verhaal. Zat er dan een macro-virus in dat Excel spreadsheet? Daar zijn zelfs MSOffice-programma toch al een jaar 10 by default tegen beveiligd? Wat is daar “buitengewoon geavanceerd” aan?
Ruud Harmsen | 5 september 2011 @ 11:12
Hier staat uitleg:
http://www.computerworld.com/s/article/9216542/Security_firm_exploits_Chrome_zero_day_to_hack_browser_escape_sandbox
Arnoud Engelfriet | 5 september 2011 @ 11:18
@Ruud: De sarcasme-tag was weggevallen. De RSA phish was buitengewoon triviaal: “Open dit bestand eens” met een kwaadaardige Flash-dinges. Dat is niet geavanceerder dan het signaturevirus (”Hoi,ik ben een virus, kopieer me aub in je signature!”).
Ruud Harmsen | 5 september 2011 @ 11:46
> dusdanig groot dat er toch een soort veiligheid is dankzij de grote nummers.
Nummers? Aantallen, hoeveelheden, toch, in het Nederlands?
Pepijn | 5 september 2011 @ 12:06
@Wim, je hebt het al 2x over paniek in een reactie op mij, ik ben echt niet in paniek hoor. Maar als bv de Iraanse overheid erachter zit, zijn zij natuurlijk juist degenen die verkeer van dissidenten ook kunnen omleiden. Ik verwacht persoonlijk echt geen problemen, ben ervan overtuigd dat hier bloed is gevloeid.
We zijn het er geloof ik wel over eens dat er iets moet veranderen in het systeem.
Aparte opmerking over wikileaks, een beetje off-topic, maar daar wil ik wel even op reageren, aangezien jij het min of meer als feit stelt.
De Afghan War Logs zijn zonder bewerking gelekt, daar heeft wikileaks (naar mijn mening onterecht) veel kritiek voor gehad, daarna is alles bewerkt. Nog steeds heeft niemand ooit ook maar 1 persoon kunnen vinden die in gevaar is geweest door Wikileaks, dat geeft de Amerikaanse overheid ook toe http://www.mcclatchydc.com/2010/11/28/104404/officials-may-be-overstating-the.html en iemand als Robert Gates denkt dat het uberhaupt allemaal niet uitmaakt http://www.mcclatchydc.com/2010/11/28/104404/officials-may-be-overstating-the.html
De cablegate documenten zijn grotendeels bewerkt op het kantoor van The Guardian in London, dat was de belangrijkste mediapartner van wikileaks in dit lek. Assange had een goed beveiligde file gelekt als verzekering voor het geval hij zou verdwijnen of zo, in 2010 was die angst niet ondenkbeeldig. Slechts heel weinig mensen hadden de key, The Guardian eiste die key ook en The Guardian heeft hem gelekt, heel apart om wikileaks hiervan de schuld te geven. Voor de feiten raad ik http://www.salon.com/news/opinion/glenn_greenwald/2011/09/02/wikileaks/index.html aan en voor een gedetailleerde mening van een onpartijdige cryptografie specialist https://unspecified.wordpress.com/2011/09/03/wikileaks-password-leak-faq/
Wim ten Brink | 5 september 2011 @ 12:35
@Ruud, nummers, aantallen… Yep. Veiligheid door grote aantallen.
@Pepijn, ik noem de paniek-reactie omdat een heleboel mensen enorm paniekerig op deze kwestie reageren. De reactie van Donner om het Internet maar niet meer te gebruiken is daar een mooi voorbeeld van. Zo staat er nu op het Twitter account van “Piet Hein Donner de volgende tekst:
Gehacked? Ja, ook hier beginnen de paniekreacties al uit te breken. Maar de account is net een maand oud, bevat 5 posts en lijkt in tegenspraak te zijn met de beweringen van de heer Donner zelf, die aangeeft eigenlijk niets te doen met Internet. Dus wat moet hij met een Twitter-account? Hier is gewoon een lolpiet geintjes aan het uithalen.
De opmerking over Wikileaks gaat over documenten die in handen van Wikileaks terecht zijn gekomen die vervolgens weer doorgelekt zijn en namen bevatten van niet alleen hoge regeringsleden maar ook de nodige informanten wereldwijd, die hierbij ook met naam en andere informatie worden genoemd. Deze personen kunnen nu mogelijk worden bedreigd! Maar ook hier werken de grote nummers/aantallen in het voordeel van de beveiliging. Want hoewel je willekeurig gevoelige informatie zo kunt vinden in deze berg documenten (zoals je een willekeurige vis uit een school kunt vangen) is het lastig om in die informatie te zoeken naar een specifiek doelwit. (Of in een school vissen zoeken naar een specifieke vis met 1 oog en een ontbrekende vin.)
Die grote aantallen doen ook hier hun werk. Er zijn dusdanig veel doelwitten gegenereerd dat het onmogelijk is dat ze ook al die doelwitten willen controleren. Het grote aantal nep-certificaten dient mogelijk als een rookgordijn omdat de hackers hun ware doelwit geheim willen houden. Wie hebben ze specifiek op het oog? Google? Microsoft en hun update-mechanisme? Skype? Of een ander doelwit? Wie deze aanval ook heeft georganiseerd maakt weinig uit, maar ze willen zich vast beperken tot een paar doelwitten en de rest is gewoon om verwarring te stichten.
Net zoals het Echelon project eigenlijk meer angst veroorzaakt dan nodig is. Waarom? Omdat zelfs met de enorme rekenkracht die Echelon heeft er maar weinig informatie uit te halen valt. Even paniek want de USA luistert alles af en dan de realisatie “wat dan nog?” Met dusdanig veel informatie moet je zorgen dat je doelgericht tewerk gaat en inzoomen op een enkel doelwit tussen al die miljoenen doelwitten. Wie dat is? Geen idee, maar die heeft pech. Voor de rest, gewoon doorzwemmen. Niets aan de hand…
Wim ten Brink | 5 september 2011 @ 12:47
Weet je wat ook ernstig is? Hackers hebben een DNS hack uitgevoerd en daarmee diverse Britse sites platgelegd! Nu zou je je meer zorgen moeten gaan maken, want indien hackers certificaten kunnen vervalsen en DNS records kunnen aanpassen behoort een Man-In-The-Middle aanval tot de mogelijkheden! Onder andere The Register lag hierdoor even plat.
Het geeft in ieder geval aan dat het huidige systeem dusdanig is verouderd dat er een nieuwe oplossing dient te komen. Tot die tijd gewoon denken aan de grote aantallen, die toch nog enige bescherming bieden.
Pepijn | 5 september 2011 @ 13:33
Ik geloof dat dit de echte Donner is: http://twitter.com/#!/phdonner
Ik vind zaken als echelon wel eng en weiger mijn ogen te sluiten voor dat soort dingen omdat het nog niet zo veel effect heeft. Dat is natuurlijk een kwestie van tijd, opslagcapaciteit meent toe, rekencapaciteit neemt toe en software die intelligent genoeg is om dit soort info goed te doorzoeken en interpreteren ontwikkelt erg snel.
Het veroorzaakt geen paniek, maar maakt me wel strijdvaardig.
Pepijn | 5 september 2011 @ 13:47
En voor wie inmiddels bijna in paniek is http://twitpic.com/6gdxaq
Corné | 5 september 2011 @ 19:47
Door deze inbraak besef ik niet alleen dat onze Public Key Infrastructure (PKI) verkeerd in elkaar zit, maar ook hoe het beter moet! Ik ben benieuwd of jullie het met me eens zijn:
De huidige PKI is gecentraliseerd opgebouwd: er zijn een paar honderd Certificate Authorities (CAs) die certificaten kunnen ondertekenen, en de handtekeningen van al die CAs worden volledig vertrouwd door webbrowsers. Er hoeft maar 1 CA gehackt te worden, en het hele systeem wordt onbetrouwbaar. Dit is precies wat er is gebeurd met Diginotar. Weliswaar wordt het systeem nu snel gerepareerd, maar mede door de zwijgzaamheid van Diginotar is het systeem een tijd lang lek geweest.
In plaats van een certificaat te vertrouwen als het is ondertekend door een enkele CA, moeten browsers in de toekomst gaan eisen dat ALLE CA’s een certificaat ondertekenen. M.a.w. er moet aantoonbare consensus zijn tussen de CAs welke certificaten geldig zijn en welke niet. CAs die tegenstrijdige certificaten ondertekenen, of die niet mee gaan met de consensus in de rest van de groep, worden niet meer als CA geaccepteerd.
Verificatie dat een bepaalde public key bij een bepaalde rechtspersoon hoort omvat nog steeds wat niet-elektronisch notaris-werk, en het zou omslachtig zijn om dit bij elke CA te moeten herhalen. Ik denk dat het praktischer is om het toe te staan dat dit bij een enkele CA kan, en dat de andere CAs dan die ene CA op zijn woord vertrouwen. Het belangrijkste van het “alle-CA’s ondertekenen” systeem blijft behouden: nieuwe certificaten kunnen niet aangemaakt worden als ze conflicteren met bestaande certificaten, zelfs als een aantal CAs gehackt wordt.
Het systeem kan nog verder verstevigd worden door een bezwaarprocedure mogelijk te maken voor als een rechtspersoon merkt dat onterecht een certificaat op zijn naam is uitgegeven. De rechtspersoon kan zich daarvoor bij elke willekeurige CA legitimeren. Die CA zal het eens proberen te worden met de CA die het betwiste certificaat heeft geverifieerd. Als overeenstemming niet lukt, dan worden voor die rechtspersoon uitgegeven certificaten gemarkeerd als “verdacht”. De rechtspersoon kan zich dan bij meerdere CAs legitimeren, totdat er voldoende consensus bestaat om 1 van beide conflicterende CAs uit de groep te gooien.
Wim ten Brink | 5 september 2011 @ 20:18
@Corné, denk je ook even aan de kosten die een nieuw systeem met zich mee brengt? Zo’n 10, 15 jaar geleden was HTTPS nog niet erg populair en ging veel verkeer gewoon onbeveiligd het Internet over. Een beveiligde site opzetten was lastig omdat certificaten duur waren en je deze ieder jaar moest verlengen. Voor veel kleine bedrijfjes en zeker voor hobbyisten dan ook onbetaalbaar.
Tegenwoordig begint HTTPS behoorlijk ingeburgerd te raken en verwacht eigenlijk iedereen dat iedere site waar je inlogt ook via SSL beschermd is. De roep om HTTPS wordt steeds groter en door het groter aanbod aan CA’s is dit ook steeds beter te betalen. Dit was ook mogelijk omdat er een groot aantal nieuwe CA’s zijn bijgekomen.
Wat uit de DigiNotar kwestie vooral naar voren komt is dat sommige CA’s het niet erg nauw nemen met de regels en beveiliging. Net op RTL-4 een interview gehoord met een ex-werknemer van DigiNotar die aangaf dat dit bedrijf een kopie bewaarde van ieder uitgegeven certificaat! En dit terwijl dat tegen de regels is! (Want wat als die kluis met kopieen gekraakt wordt?)
En wat ik al aangaf, deze hack was bedoeld om een specifiek doelwit mee aan te vallen. Op Security.nl wordt al aangegeven dat de hack vooral bedoeld was om de Iraanse Internetters te bespioneren en dan vooral diegenen die de overheids-censuur probeerden te omzeilen. Opvallend omdat DigiNotar eigenlijk alleen voor de Nederlandse markt wordt gebruikt.
Toch zal er een systeem moeten komen dat veiliger is dan het huidige systeem. Maar een systeem waarbij meerdere CA’s een certificaat geldig moeten verklaren? Nee, te kostbaar! Wat misschien wel een hulpmiddel is, is het beter controleren op het Internet-verkeer als het gaat om het verifieren van certificaten. Deze hack is immers deels ontdekt doordat een Nederlands certificaat opeens massaal vanuit Iran werd opgevraagd. Dat is een stevige alarmbel die dan rinkelt! En hoewel beveiliging in orde moet zijn is een goed waarschuwings-systeem dat waarschuwt over dergelijke hacks in een vroeg stadium ook enorm belangrijk. En natuurlijk een snel update-systeem voor browsers en besturings-systemen. Mozilla, Google, Opera en Microsoft hebben allen best snel gereageerd. Apple met Safari blijkt echter wat aan de trage kant en in een situatie als deze is dat behoorlijk funest.
Ik bedenk mij ook opeens dat er veel mobiele devices zijn, waaronder smartphones, tablets, PDA’s en dergelijke die natuurlijk ook certificaten gebruiken. Ben benieuwd of die ook allemaal automatisch worden bijgewerkt! Heeft daar al iemand over nagedacht?
Ruud Harmsen | 5 september 2011 @ 21:03
De menselijke factor, zo sterk als de zwakste schakel, de kinderen van de schoenlapper lopen op kapotte schoenen, en meer van die speekwoorden:
http://www.nu.nl/internet/2607758/diginotar-negeerde-misbruik-en-was-slecht-beveiligd.html
Ruud Harmsen | 5 september 2011 @ 21:08
Wim ten Brink:
De certificaten zitten op de sites, niet op de clients.
http://nl.wikipedia.org/wiki/Secure_Sockets_Layer
George | 5 september 2011 @ 21:49
Ik vindt de discussie wat uit de hand lopen, ook hier, en in de media krijg je dan meteen indianenverhalen, zoals het bovenstaande.
Het is GEEN probleem dat Diginotar een kopie van het “certificaat” bewaart dat zijzelf heeft uitgegeven. Er is niets bijzonders aan die procedure en het is nodig als het certificaat (ooit) ge-reissued moet worden.
Het maakt niet uit of deze “kluis met kopieen” gekraakt wordt, er staat geen vertrouwelijke informatie in!
Hoe certificaten werken is kortweg zo:
- Je wilt een certificaat, dan genereer je een Private Key en een Public Key;
- De Private Key is het geheime deel en wordt NOOIT gedeeld (ook niet met de CA);
- De Public Key stuur je naar de CA in de vorm van een Certificate Request;
- De CA heeft ook een (geheime) Private Key en een publieke Public Key;
- Voor het uitgeven van een certificaat encrypt (signed) de CA jouw Public Key met zijn Private Key;
- De publieke keys zijn dus publiek, voor iedereen beschikbaar;
- Je ontvangt het ge-signed kopietje van je publieke key van de CA. Dit is je certificaat (in essentie).
Je ziet dat de Private Key nooit over het internet wordt verstuurd. Het “grapje” is dat je dus “encrypt” met de Private Key en “de-crypt” met de Public Key.
Als je de public key van een website uit het certificaat kan de-crypten met de publieke key van de CA, dan is het certificaat geldig (want gesigned met de geheime Private Key van de CA), en kan je die publieke key van de website gebruiken om data te de-crypten.
Dit is niet een uitleg van hoe het hele SSL of TLS protocol werkt, maar hoe de basis van X509 certificaten werken voor het vaststellen van de geldigheid.
George.
Arco | 5 september 2011 @ 21:54
De hamvraag is of Diginotar gebruik maakt van exoneratieclausules in haar contracten en zo ja of die naar redelijkheid en billijkheid kunnen worden toegepast. Daar gaat de rechter in hoofdlijnen naar kijken, de rest doet er minder toe.
Pandy | 5 september 2011 @ 21:58
Maar zijn nu alleen Iraniërs in Iran gehacked, of ook Iraniërs in Nederland?
Robert | 5 september 2011 @ 22:26
Alhoewel dit zeker zeer schadelijk is en na Comodo nog maar weer eens laat zien dat PKI niet de heilige graal is, moet dit toch ook niet overschat worden. Er dient immers nog steeds een MITM-attack plaats te vinden om het certificaat te gebruiken.
(en dus @Pandy: nee, Iraniërs in Nederland hebben hier - tijdens dezelfde “hack” in ieder geval - geen last van gehad. Tenzij ze uit weemoed via een Iraanse VPN het net op gaan, maar dat verwacht ik gek genoeg niet..
)
Robert | 5 september 2011 @ 23:20
Fox-IT interim rapport is beschikbaar op http://tweakimg.net/files/upload/Operation+Black+Tulip+v1.0.pdf
@Pandy: Apart genoeg linkt dit naar http://www.youtube.com/watch?v=_eIbNWUyJWQ wat laat zien dat er ook in Nederland en omringende landen er een vals *.google.com certificaat opgevraagd is, wat weer zou betekenen dat dit ook in Nederland effect heeft gehad.
Dat kan ik niet zo 1-2-3 verklaren..
George | 5 september 2011 @ 23:24
@robert Vanzelf gaat dat niet, dus is er sprake van malware of b.v. een proxy instelling.
Robert | 5 september 2011 @ 23:25
@George: Precies. Dat is wat mij zo bevreemd; dat zijn dan nog een flink aantal mensen die specifiek proxy’en náár Iran toe?
Piet | 5 september 2011 @ 23:32
@Wim(#40):
Dat was al vanaf het prille begin van deze affaire duidelijk.
@Ruud(#42):
Het Diginotar CA certificaat zit wel op de clients. Ik heb al gezocht naar een manier om dat in Android verwijderd te krijgen, maar kon zo snel niets vinden.
@Pandy(#45):
Alleen personen van wie het internetverkeer langs servers van de Iraanse overheid gaat. (Ah, Robert was me voor. @Pandy: MITM staat voor man-in-the-middle; Iran moet echt jouw verkeer kunnen afvangen, decrypten (met het nepcertificaat) en weer encrypten (met bijv. het gmail-certificaat) en natuurlijk ook de andere kant op.)
Piet | 5 september 2011 @ 23:45
Is het nu niet hoog tijd voor een “I am paranoid!”-optie in Firefox (en andere browsers)?
Functionaliteit als volgt:
- iedere keer dat een nieuw certificaat wordt ontvangen krijgt de gebruiker hiervan een melding met aanduiding van de CA en de fingerprint van het certificaat;
- iedere keer dat een nieuw certificaat wordt ontvangen van een site waar de browser al een certificaat van had wordt de melding nog wat indringender, in ieder geval als het oude certificaat nog lang niet expired is en/of de CA is gwijzigd.
Aan de hand van de CA en de fingerprint kan de gebruiker zelf proberen te controleren of het certificaat juist is. De gebruiker kan zelf bepalen hoever hij hierbij gaat, en zal dat natuurlijk laten afhangen van de gevoeligheid van de informatie die hij met die site gaat uitwisselen.
Lijsten met fingerprints van de belangrijkste sites kunnen eenvoudig overal op internet beschikbaar worden gemaakt.
Robert | 5 september 2011 @ 23:50
@Piet: Controle aan de gebruiker overlaten werkt niet. Hoe maak je het verschil duidelijk aan de gebruiker? “Let op: uw browsergegevens worden mogelijk onderschept door een kwaadwillende overheid!”? Zo gaat DigID ook geen zieltjes winnen.
Laat staan de (financiële) impact die het heeft op normale sites die om een normale administratieve reden van CA wisselen.
Google ondersteunt inmiddels met Chrome versie 13 het zgn. ‘Public key pinning’, waar een afgeleide van jouw idee in gebruikt wordt.
Zie o.a. http://ssl.entrust.net/blog/?p=615
Met public key pinning worden bepaalde fingerprints ge-whitelist. Dit is ook niet ideaal omdat het niet schaalt, maar het is alvast een kleine verbetering.
Wim ten Brink | 6 september 2011 @ 0:31
@George, als de CA kopieen bewaart van de private key dan is dat een veiligheids-risico. Want wat als een boze medewerker deze kopieen gewoon even op een USB stick meeneemt en per opbod verkoopt? Een private key hoort gewoon uniek te zijn. Een CA hoort daar geen kopie van te hebben. Dat is hetzelfde als een autodealer die van iedere auto die hij verkoopt een extra contactsleutel bewaart voor het geval dat… Tja, waarvoor eigenlijk? Het enige nut is dat een medewerker van die dealer vervolgens die sluetels jat en bij alle klanten even langs gaat om hun nieuwe auto’s te jatten. Een CA die een certificaat bewaart? Foute boel! Mocht een klant zijn certificaat kwijt raken dan maak je gewoon een nieuwe.
Het gaat niet om kopieen van de public keys die DigiNotar bewaarde, maar kopieen van de private keys. Om public keys maakt niemand zich zorgen.
Wim ten Brink | 6 september 2011 @ 0:39
@Arco, de hamvraag is hoe snel DigiNotar failliet gaat! Vasco heeft DigiNotar ooit gekocht voor 10 miljoen Euro en dat geeft ook ongeveer aan wat het bedrijf uiteindelijk waard zou kunnen zijn. Dat in combinatie met een aansprakelijkheidsverzekering die ze vast hebben en die ook de nodige miljoenen kan ophoesten aan schadevergoedingen (tot een maximum bedrag!) denk ik dat bij een totale schadeclaim van 40 tot 50 miljoen Euro het bedrijf al meteen opgedoekt kan worden. De enige reden waarom Diginotar nog leeft is wegens het onderzoek naar deze hack.
Gevolgen voor Vasco? Weinig tot geen, denk ik. Ja, een forse afschrijving omdat ze DigiNotar ooit kochten en nu meteen moeten afstoten. Ze hadden Diginotar nog niet eens een jaar in bezit dus al te verantwoordelijk is Vasco misschien niet. Tenzij Vasco bij de overname ook meteen structurele wijzigingen heeft uitgevoerd waardoor deze hack mogelijk werd! Ook zal sterk worden gekeken naar de rol van Vasco in het hele gebeuren en mogelijk dat een deel van de verantwoording ook naar Vasco kan worden geschoven.
Gaat Vasco mogelijk ook failliet. (Sowieso heeft hun reputatie nu een enorme deuk opgelopen.)
Wim ten Brink | 6 september 2011 @ 0:43
@Pandy, voor een man-in-the-middle aanval moet je niet alleen de certificaten vervalsen maar ook de netwerk-verbindingen omleiden naar je eigen servers. Dat kan indien je in de DNS registers het een en ander kunt aanpassen of op de client PC’s de HOSTS kunt aanpassen. Beiden zijn best lastig om uit te voeren, tenzij je de controle hebt over de internet providers in een bepaalde omgeving. Want in dat geval kun je de mensen die aan die ISP’s hangen dus misleiden. Grote kans dus dat dit in Iran is gebeurt maar buiten Iran zal iedereen nog wel redelijk veilig zijn.
Piet | 6 september 2011 @ 1:41
@Robert:
Ik denk aan een optie speciaal voor de gebruikers die weten wat ze doen en niet volledig willen vertrouwen op de controle die de browser zelf uitvoert (en waar gmail-certificaten van Diginotar vrolijk doorheen fietsen…). De normale gebruiker zal zo’n “I am paranoid!”-optie niet gebruiken. Stop ‘m desnoods weg in de about:config van FF.
Met mijn optie aangevinkt zouden de (paranoïde) Iraanse internetters op hun scherm een overduidelijke melding hebben gekregen dat gmail is overgestapt op Diginotar als CA.
Er hoeft niet bij te staan dat er iets mis is, zeker niet als de checks die de browser zelf uit kan voeren niet op een probleem duiden. Gewoon wat informatie die de paranoïde gebruiker in staat stelt om zelf een oordeel te vormen. Nu konden ze dat niet, de browser accepteert ongevraagd een gmail-certificaat van Diginotar.
Als zelfs maar een klein deel van de gebruikers zo’n optie aan heeft staan, zal een vals certificaat snel door de mand vallen. De reden dat de hele affaire nu aan het licht is gekomen is dat Chrome voor gmail blijkbaar zelf zo’n sanitycheck uitvoert, waardoor een gebruiker onraad kon ruiken.
(Misschien zijn er al browserextensies die iets soortgelijks doen?)
@Wim:
George schrijft nu juist dat dat niet gebeurt, omdat de CA die private key nooit in handen krijgt. Het bewaren van een gegenereerd certificaat is dus compleet onschuldig. Sterker nog, iedere gebruiker van de website krijgt die certificaten op zijn computer.
Wim ten Brink | 6 september 2011 @ 14:55
In werkelijkheid zijn dat niet zoveel gebruikers! De meeste gebruikers denken te weten wat ze doen maar in werkelijkheid snappen ze dingen maar half, wat juist een groter risico met zich mee kan brengen! Die mensen van DigiNotar zullen ook wel gedacht hebben dat ze wisten wat ze deden. Geen virusscanners, eenvoudige wachtwoorden, ja, ja… Uiteindelijk is het een bedrijf vol prutsers die meer aandacht gaven aan winst maken en geld besparen dan dat ze daadwerkelijk veilig bezig gingen. Ze gingen voor gemak, niet voor veiligheid…
Dat klopt niet helemaal want zonder private key kan een CA geeneens een certificaat genereren. Nu zijn er twee methodes die CA’s toepassen: of de gebruiker maakt zelf een keypaar aan en laat de public key certificeren, of de gebruiker bestelt een compleet keypaar en installeert deze op zijn eigen systeem. In het eerste geval heeft George gelijk. Veel CA’s ondersteunen ook de tweede methode…
Voorbeeld, bij StartSSL kun je voor weinig geld certificaten kopen. Een SSL certificaat kun je daar via een eenvoudige wizard aanmaken waarbij je of een wachtwoord opgeeft van 10 letters en/of cijfers of je voert je private key in! Het resultaat is een certificaat, klaar voor gebruik…
Wim ten Brink | 6 september 2011 @ 15:30
Maar iedereen kan nu al eenvoudig het certificaat controleren van beveiligde websites! Zo’n beetje iedere browser heeft wel ergens een icoontje met sleutel of zo waar je op kunt klikken als je paranoide bent. Maar om dit nu iedere keer weer handmatig te moeten doen? En dat voor mogelijk iedere kleine wijziging die in een certificaat plaatsvindt? Na enkele malen een vals alarm klikken de meeste gebruikers een dergelijke melding gewoon weg of zetten die optie uit. Veel mensen zijn namelijk gemakzuchtig bezig. Helaas gaat dat wel ten koste van de beveiliging, zoals DigiNotar heeft aangetoond.
Daarnaast, een dergelijke Man-In-The-Middle aanval vindt plaats in twee delen. Vervalsen van het certificaat en het omleiden van het Internet-verkeer. En dat laatste gebeurt meestal op locaal niveau, binnen een provider of zoals in dit geval binnen alle providers die de locale regering kan controleren. Het probleem van een dergelijke paniek-knop ontstaat wanneer mensen in Iran opeens die knop gebruiken en opeens weer wereldwijd paniek uitbreekt! (Of de providers vangen ook het gebruik van die knop af en dan wordt er niemand gewaarschuwd. Ze zitten immers in het midden en hebben dus controle over dit dataverkeer!)
Een ander probleem is dat er mensen zullen zijn die expres vals alarm zullen roepen over bepaalde sites. Dat is nog het meest vervelende, zeker indien hiervoor malware wordt toegepast om overal valse alarms te genereren. Een dergelijk waarschuwings-systeem gaat dan snel ten onder door die druk.
Bedenk verder dat geen enkel systeem waterdicht is. Hou er altijd rekening mee dat je internet-communicatie afgeluisterd kan worden en sta dan ook stil welke risico’s je vervolgens loopt. En in de praktijk valt dat vaak best mee. Zo ook in deze situatie waar eigenlijk alleen de Iraanse dissidenten de slachtoffers waren. En dan nog, gezien de hoeveelheid data die men hiervoor moet verwerken denk ik dat er nog veel van hen aan ontsnapt zijn.
Om ook even over na te denken… In 2012 zijn er nieuwe verkiezingen in Iran. Deze aanval is voor de huidige regering dan ook ideaal om nog wat extra dissidenten op te pakken en te berechten. Dit is dan ook deels een prestige-hack geweest, naar mijn mening. Gewoon even laten zien aan de bevolking hoe goed Iran is op het gebied van Internet-spionage.
Maar even een vraagje… Zijn er al gegevens bekend van slachtoffers van deze hack? Zijn er wel slachtoffers of is het meer de chaos en verwarring die slachtoffers maakt?
Wim | 6 september 2011 @ 17:45
De overheid heeft zijn certificaten uitbesteed aan Diginotar. De vraag is welke maatregelen heeft de overheid genomen om de veiligheid te waarborgen. Wordt er regelmatig een security audit uitgevoerd op Diginotar. Zoja waarom is dit probleem dan niet eerder ontdekt. Zo nee, hoe weet de overheid dat dit bedrijf zijn zaken op orde heeft? In dat geval is ook de overheid aansprakelijk en nalatig geweest
Wim ten Brink | 6 september 2011 @ 18:26
Wim, ik denk dat de overheid zelf, net als DigiNotar, ook gewoon te gemakzuchtig bezig is geweest. Sowieso is de overheid van nature al erg traag en loopt men altijd achter op ICT-gebied omdat de mensen met ervaring meestal elders een beter betaalde baan kunnen vinden. Ondertussen heeft de overheid DigiNotar gewoon overgenomen en worden er de nodige experts ingehuurd om te onderzoeken wat er precies is gebeurt, wie er achter zat, wat de totale schade is en eventueel wie er strafrechtelijk vervolgd dient te worden.
Als het gaat om ICT-projecten is de overheid bijna altijd afhankelijk van externe partijen en heeft de overheid nog wel eens de neiging om op bepaalde controles dusdanig te bezuinigen dat er van deugdelijke controles geen sprake meer is. En denk maar niet dat verkiezingen de volgende regering slimmer zal maken want die personen die we kiezen zijn uiteindelijk niet diegenen die het werk moeten uitvoeren. De regering die we kiezen bepalen alleen het beleid. De ambtenaren die gewoon betaald krijgen ongeacht wie er regeert bepalen uiteindelijk wat er wel en niet gebeurt, ook al moeten ze daarbij tegen de wensen van de regering in gaan…
Piet | 7 september 2011 @ 1:03
@Wim(#57):
Dat klopt gewoon niet. Lees de reactie van George nou eens goed, hij legt toch duidelijk uit hoe het in elkaar zit. De CA heeft de private key van de website niet nodig, en die private key zit ook niet in het certificaat. En nogmaals, die certificaten staan ook gewoon op jouw computer nadat je de website hebt bezocht.
Zelfs al zou Diginotar voor hun klanten het keypaar hebben gegenereerd (wat mij zeer onwaarschijnlijk lijkt), dan zit die private key nog steeds niet in het certificaat, dus is er nog steeds niets aan de hand als Diginotar al die certificaten onveilig heeft opgeslagen. Daar volgt niet uit dat ook de private key’s worden bewaard, dat lees alleen jij erin.
Tuurlijk, maar ik heb geen optie om mijn browser mij te laten vertellen dat ik een bepaald certificaat VOOR HET EERST gebruik. Ik hoef een certificaat maar 1x op echtheid te controleren, maar dan moet ik wel weten dat ik een nieuw certificaat heb ontvangen.
Die Iraanse internetters kregen een nieuw certificaat voor de kiezen zonder het te merken. Je kunt niet verwachten dat je IEDERE sessie gaat controleren of het wel klopt. Per kritieke site (als gmail) één check per 2 of 3 jaar is niet echt een probleem lijkt me zo. (Nee, certificaten worden niet elke week “een klein beetje” gewijzigd.)
Nou ja, als je het simpele nut van zo’n optie niet wilt zien, dan hoeft dat natuurlijk niet. Maar laat je lange zijspoor-ik-moet-per-se-mijn-kennis-spuien-verhalen liever zitten, neem mij niet kwalijk maar dank je feestelijk.
Wim ten Brink | 7 september 2011 @ 11:48
@Piet, even het gehele proces voor het maken van een certificaat doornemen… Het begint met een key-paar die de gebruiker op zijn eigen systeem heeft. De private key hiervoor behou je zelf, de public key wordt met extra data verstuurd naar de CA. De CA gebruikt vervolgens hun eigen private key om van deze data een certificaat te maken. Dat certificaat gaat weer terug naar de gebruiker en wordt door de webserver weer doorgestuurd naar de browsers die deze vervolgens kunnen valideren. Tot zover heeft George gewoon gelijk.
Maar de CA kan naast het tekenen van public keys ook private keys genereren voor hun klanten. StartSSL doet dit, bijvoorbeeld. Je meldt je aan en ze versturen je een certificaat met daarin een public en private key. De CA hoeft daarna alleen de Public key hiervan te bewaren en de gebruiker logt op de site in via hun private key. De CA moet in dit geval niet de private key van de klant bewaren. DigiNotar schijnt dit juist wel gedaan te hebben!
Het voordeel van wat StartSSL doet is dat je dus een certificaat plus private key hebt, waarbij je die private key op meerdere servers tegelijkertijd kunt gebruiken. De standaard private key onder IIS is namelijk machine-afhankelijk. Je moet er natuurlijk wel voorzichtig mee zijn want als die private key in verkeerde handen valt…
Vergeet niet dat DigiNotar meer deed dan alleen SSL certificaten genereren. Indien DigiNotar inderdaad die private keys bewaarde die in opdracht van klanten zijn aangemaakt dan is dat een enorm risico indien deze private keys in verkeerde handen vallen. Immers, die private key is al voldoende om de communicatie mee te decrypten! Zelfs indien een bedrijf elders een nieuw certificaat genereert maar dezelfde private key gebruikt!!
Wim ten Brink | 7 september 2011 @ 12:00
Eigenlijk schijnt het een Iranier geweest te zijn die de hack als eerste opmerkte toen hij met Chrome naar de website van Google ging. Chrome controleert kennelijk net iets verder dan normaal en kon ontdekken dat die Iranier een certificaat gebruikte dat normaal niet bij Google hoort. Dus een popup met waarschuwing, ook al leek het certificaat verder in orde.
Een systeem waarbij de gebruiker zelf moet controleren of een certificaat klopt gaat ten onder aan het gebrek aan gebruikers-gemak. Beter is het indien browsers dergelijke controles automatisch kunnen uitvoeren en dat kan vrij ver geautomatiseerd worden. Voorbeeld: Iranier X gaat bladeren naar https://iusmentis.nl en krijgt een certificaat van DigiNotar. De browser kan op dat moment dit certificaat ook doorsturen naar een centrale server die vervolgens registreert dat bij deze site dit certificaat behoort. Indien het certificaat al eerder bekend was is er niets aan de hand. Is het certificaat nog onbekend dan gaat de browser eerst goedgelovig verder, maar het centrale registratie-systeem gaat vervolgens de betreffende site vanuit meerdere plaatsen op de wereld opnieuw vragen om even het certificaat aan te leveren. Indien al die locaties hetzelfde certificaat opleveren is er niets aan de hand. Als er afwijkingen zijn dan worden die onthouden en die moeten dan verder uitgezocht worden. Dat uitzoekwerk zal de nodige tijd kosten dus die centrale organisatie is daar wel enkele uren mee bezig. De gebruiker zelf zal ondertussen wel klaar zijn met browsen en die wil je niet uren laten wachten.
Mocht uiteindelijk geconcludeerd worden dat het een vervalst certificaat betreft (omdat geen enkel checkpoint het betreffende certificaat aanlevert of omdat het onderzoek uitwijst dat het is vervalst) dan kan het betreffende certificaat direct geblokkeerd worden door de browser. Als Iranier X dan weer opnieuw naar de site gaat (of tijdens het browsen) dan krijgt hij daarover meteen een waarschuwing.
George | 7 september 2011 @ 13:25
Hey Wim, bel/tweet me even de volgende keer dat je een wachtwoord nodig hebt of je PIN wilt wijzigen. Ik weet nog wel een paar goede codes.
Het is “niet handig” om je private key door anderen te laten genereren. Als iemand dat aanbiedt “omdat het makkelijk is” dan is dat voor rekening van de sufferd die daarvoor gaat.
Het hele idee is dat je private key nooit over een onveilig medium (als Internet) wordt verstuurd. Je PIN/wachtwoord geef je ook niet over de telefoon aan iemand door.
Private Keys kunnen “exporteerbaar” zijn, zodat je ze op meerdere systemen kan gebruiken. Zo worden ze standaard aangemaakt door IIS; voor exporteren gebruik je de Certificates Management Console.
Je kan een Private Key ook niet exporteerbaar aanmaken; dat is veiliger, “duh”.
Keys op (USB) access-tokens of voor het identificeren van systemen/computers worden vaak niet-exporteerbaar aangemaakt, om voor de hand liggende redenen.
George.
Wim ten Brink | 7 september 2011 @ 13:47
@George, natuurlijk is dat niet handig maar het gebeurt wel! Mede ook omdat gebruikers vaak onwetend zijn over hoe je met dit soort beveiliging om moet gaan. Maar goed, zelf heb ik bij StartSSL gewoon eerst zelf via IIS een CSR aangemaakt en die opgestuurd zodat ik zeker weet dat de private key van mijn eigen systeem is gebruikt. Probleem is dan wel dat ik mijn eigen private key dus ook veilig moet stellen indien mijn server ooit vervangen moet worden of als ik een andere server wil gaan gebruiken. Die private key moet dan naar die andere computer. En daar zit het “gemak” hem dus, want StartSSL geeft je eigenlijk alleen die sleutels zodat je daarmee op hun site kunt inloggen. (Client authentication noemen ze dat.) Dat ze daarnaast de mogelijkheid bieden om de publieke key ervan te gebruiken voor het genereren van SSL certificaten is leuk en aardig, maar is eigenlijk niet de bedoeling.
En ja, met IIS kun je inderdaad je certificaten exporteren, indien ze exporteerbaar zijn. Handig, maar ook weer riskant want als die keys door malware worden ge-exporteerd… Of als het export-bestand in verkeerde handen valt…
Domheid en gemakzucht gaan vaak hand-in-hand met elkaar. Mensen kiezen sneller voor de eenvoudige methode dan de veilige methode.
mitopics - onafhankelijk IT-advies | Over zorgplichten van online dienstverleners | 20 september 2011 @ 20:35
[…] zijn we het niet eens met Arnoud Engelfriet zijn constatering dat het lastig zal zijn om schade op DigiNotar te verhalen. Waarbij overigens opgemerkt moet worden […]