Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 97, views: 26.330 •

Microsoft, Google en Mozilla brengen software-updates uit om de root-key van DigiNotar te verwijderen. DigiNotar, dat veel werk voor de Nederlandse overheid verricht, verstrekte een ongeldig ssl-certificaat voor subdomeinen van Google.com.

DiginotarDoor het ongeldige ssl-certificaat kon de Iraanse overheid een man in the middle-aanval op zijn inwoners uitvoeren, door het verkeer van en naar de Gmail-servers te onderscheppen. Internetgebruikers zouden daarvan niets merken, omdat het Nederlandse bedrijf DigiNotar een vals ssl-certificaat voor alle subdomeinen van Google.com had uitgegeven.

Mozilla heeft daarom aangegeven zeer binnenkort met een update voor Firefox, Thunderbird, SeaMonkey en Firefox Mobile te komen waarin het zogenoemde root-certificaat van DigiNotar ongeldig wordt verklaard. Daardoor zijn certificaten die onder de vlag van dit root-certificaat zijn uitgegeven, ongeldig. Microsoft heeft de root-key van DigiNotar uit zijn lijst met vertrouwde certificaten gehaald, waardoor gebruikers van Internet Explorer op nieuwe Windows-versies een foutmelding zouden moeten krijgen als een certificaat met de root-sleutel van DigiNotar is ondertekend.

Ook Google gaat het certificaat intrekken, al waren Chrome-gebruikers sowieso niet vatbaar voor het beveiligingsprobleem: Google heeft in de code van Chrome aangegeven dat alleen bepaalde partijen certificaten voor Google.com mogen uitgeven, en daar was DigiNotar er geen van. Als gevolg van het intrekken van de certificaten krijgen gebruikers een foutmelding als ze naar een beveiligde website met een DigiNotar-certificaat proberen te gaan. Desgewenst kunnen ze de website toch bezoeken, maar de identiteit van de website kan dan niet worden bevestigd.

Woordvoerder Jochem Binst van Vasco Security, dat de eigenaar is van DigiNotar, stelt dat dat geen gevolgen heeft voor het werk dat DigiNotar voor de overheid doet. Zo regelt DigiNotar het ssl-certificaat van DigiD, evenals de ssl-certificaten die bedrijven en instellingen gebruiken om vertrouwelijk met de overheid te communiceren. Het certificaat voor DigiD is bijvoorbeeld door een aparte root-autoriteit uitgegeven, speciaal voor de overheid.

Binst zegt niet te weten waarom DigiNotar een certificaat heeft uitgegeven voor Google, terwijl het dat helemaal niet had mogen doen. Wel zal het bedrijf later op de dag met een verklaring komen.

Het is niet de eerste keer dat een root-autoriteit ongeldige ssl-certificaten uitgeeft: Comodo heeft in maart ongeldige certificaten uitgegeven voor domeinen van Google, Yahoo, Mozilla en Microsoft. Opvallend is dat het certificaat van DigiNotar bijna twee maanden onopgemerkt is gebleven; inmiddels heeft DigiNotar het certificaat ingetrokken, maar daarmee kon niet worden voorkomen dat webbrowsers collectief het vertrouwen in DigiNotar opzegden.

Volgens de Electronic Frontier Foundation bevestigt de DigiNotar-blunder de kwetsbaarheid van certificaat-autoriteiten, terwijl de betrouwbaarheid van https-verbindingen zo zwaar leunt op die partijen. "Vandaag de dag vertrouwen internetgebruikers op certificaat-autoriteiten om hun privacy tegenover overheden te beschermen. We vragen ons af of die deze last wel kunnen dragen", schrijft de burgerrechtenorganisatie.

Gerelateerde content

Alle gerelateerde content (34)

Reacties (97)

Reactiefilter:-197095+168+217+32
Erg netjes dat ze dat zo snel allemaal hebben geregeld..

Wel jammer dat je dan toch zelf je browser moet updaten wat natuurlijk niet iedereen doet.

@Hieronder...

Iets wat niet opgemerkt is kun je ook niet verhelpen ? Het is dus pas gister aan het licht gekomen en ze nemen dus meteen stappen...

En ook zoals hieronder.. het is niet aan de browser makers om dit op te lossen en toch doen ze het.

[Reactie gewijzigd door Brummetje op 30 augustus 2011 09:44]

Volgens mij kunnen we uit het artikel niet opmaken dat de updates al klaar staan, dus het is nog even afwachten hoe snel de browsermakers actie zullen ondernemen. de plugins beschikbaar stellen.

edit n.a.v. bericht hierboven

[Reactie gewijzigd door funk-e op 30 augustus 2011 09:45]

Volgens mij kunnen we uit het artikel niet opmaken dat de updates al klaar staan
Zo te zien hoeft Microsoft voor IE op Windows Vista en nieuwer helemaal geen software update door te voeren omdat Internet Explorer on line de certificaten verifieert tegen de Microsoft Certificate Trust List.en Microsoft het Diginotar cerificaat daarvoor direct heeft ingetrokken

Voor Window XP en Server 2003 versies zal vermoedelijk nog wel een update moeten komen.

[Reactie gewijzigd door hAl op 30 augustus 2011 10:15]

Erg netjes dat ze dat zo snel allemaal hebben geregeld..
Euhhhh... Wat mis ik?
Opvallend is dat het certificaat van Diginotar bijna twee maanden onopgemerkt is gebleven.
Tja, het is maar wat je snel noemt.
Zodra het bekend werd hebben de browsermakers snel actie ondernomen om het certificaat te verwijderen. Dat is wat Brummetje bedoelde denk ik en daar heeft die toch gelijk in?

[Reactie gewijzigd door Marcade op 30 augustus 2011 09:32]

Het nieuws zelf is gister bekend geworden, dus als de grote partijen vandaag reageren is dat snel ja.

Het is niet aan Mozilla/Microsoft/Google om alle SSL-certificaten dagenlijks na te lopen ;)
Normaal heb je natuurlijk niet zoveel aan alleen een SSL certificaat voor een Google domein. Er is natuurlijk geen enkele DNS server welke bezoekers naar jouw server doorstuurd zodat je ook een man-in-the-middle attack kunt uitvoeren.

In Iran is dat anders, omdat Iran hun DNS servers kunnen wijzigen om via een soort van proxy het verkeer te onderscheppen. De proxy zorgt voor de blauwe blak (ik ga er vanuit dat dit niet het EV-SSL certificaat betreft) in de browser verschijnt en zet alle verzoeken door naar de 'echte' server en geeft daarna het antwoord weer terug.

Wij gebruiken een soort gelijke techniek om Chrome uitdates te cachen. Je wilt niet dat ruim 150 clients allemaal dezelfde software gaan downloaden. Via caching door middel van een transparante proxy wordt op deze manier slechts eenmaal de Chrome update gedownload per 4 uur.

Iran gebruikt deze techniek dus om mailverkeer te onderscheppen..
Normaal heb je natuurlijk niet zoveel aan alleen een SSL certificaat voor een Google domein.
quote uit de ettercap manual page: "SSL support : you can sniff SSL secured data... a fake certificate is presented to the client and the session is decrypted."
Er is natuurlijk geen enkele DNS server welke bezoekers naar jouw server doorstuurd zodat je ook een man-in-the-middle attack kunt uitvoeren.
http://openmaniak.com/ettercap_filter.php

edit: na het lezen van mijn comment vraag ik me af of ik wel kan lezen/schrijven......

[Reactie gewijzigd door goestin op 30 augustus 2011 10:02]

SSL certificaat misbruik voor dummies (samevatting):
Stap 1: 'gratis' hotspot opzetten op b.v. een terasje.
Stap 2: je eigen dns server via dhcp uitgeven.
Stap 3: Wachten op de eerste dodo die op de desbetreffende site wil inloggen en het valse SSL certificaat naar de client sturen.
Zonder browserupdate is het nu eenmaal niet mogelijk om 't certificaat in te trekken - eigenlijk zou men hier een apart update-kanaal voor moeten gebruiken.

(volgens mij is er binnen het SSL-gebeuren ook een voorziening om dit te kunnen doen...)
Voor zover ik weet is er binnen PKI-crypto een voorziening om "normale" certificaten in te trekken door middel van een CRL (certificate revocation list) die uitgegeven wordt door de CA. Zo zou Diginotar publiekelijk kunnen aangeven dat het google.com-certificaat ongeldig is. Voor zover ik weet is er géén voorziening voor de browsermaker om de certificaten van hele CA's in te trekken -- misschien omdat hem dat teveel controle geeft over de CA's die gebruikers gebruiken, of omdat ze de infrastructuur om die CRL zelf te hosten niet willen opzetten.

Edit: zo te zien heeft Diginotar dat inderdaad al gedaan: http://www.google.co.uk/s...da6158b094b225a&hl=en -- Helaas voor hen zijn ze nu alsnog hun reputatie kwijt :)

[Reactie gewijzigd door dazjorz op 30 augustus 2011 09:55]

Met een recente IE hoef je ook niet je browser te updaten.
Dat is wel mogelijk, in Firefox can je bijvoorbeeld een Certificate Revocation List importeren. Het enige probleem is dat dat dus handigmatig werk van de gebruiker vereist, dan is een browser update dus simpeler.
"..eigenlijk zou men hier een apart update-kanaal voor moeten gebruiken."

via een SSL-verbinding dan gelijk ook? en dan laat je Diginotar weer de certificaten voor leveren?

;)

Volgens mij wil je nu net liever niet dat de identiteits-vaststelling makkelijk via geheimzinnige 'backdoors' beinvloed kan worden en daarom zou het juist meer gevaar opleveren om zulk een 'backdoor' te scheppen...
het is waarschijnlijk enkel een praktische oplossing voor veelgebruikte domeinen om met 'root-certificaten' te werken die niet continue gechecked worden, dat om extra 'load' op de certifcaatservers te beperken... maar juist dat is ook een extra gevaar, zeker nu blijkt dat een vals certicaat 2 maanden kon bestaan zonder dat er een 'waarschuwing' gegeven werd dat er dus illegale rootcertifcaten in omloop waren...

wat dat betreft zou het veiliger zijn als zelfs rootcertifcaten toch minimaal eens per 48 uur iig op geldigheid gecheked worden en bij valse meldingen hierover ook gelijk een waarschuwing uitgegeven wordt, inclusief de uitgevende instantie....
in zo'n geval zou men binnen 48 uur tegen zulke ilegale certificaten kunnen optreden en is het niet meer winstgevend die te misbruiken voor langdurigere spionage-doeleinden (wat veel 'afluisterwerk' meestalw el is, dat zijn langdurende operaties die vaak niet bedoeld zijn om binnen 48 uur weer ontdekt te worden)
Je kunt handmatig het DigiNotar certificaat uit de lijst halen (bij Firefox, IE weet ik niet).

Maar worden revocation lists niet apart opgehaald bij FF en IE?

Edit: er zijn er meer die hiervan op de hoogte zijn zo te zien :)

[Reactie gewijzigd door [Yellow] op 30 augustus 2011 10:00]

Pale Moon gaat geen update uitgeven:
No, the certificate has been revoked and this should cover anyone using it for on-line SSL connections. The update would be a lot of work for simlply deleting a certificate from the built-in certificate store, which you can do yourself as well (if you are really worried that the certificate revocation won't be picked up by Pale Moon) by following the steps here: http://support.mozilla.co...eleting-diginotar-ca-cert
Als je niet afhankelijk wil zijn van browserupdate's in dit soort gevallen: http://my.opera.com/secur...-authorities-are-hacked-2
Hm Ja dit is inderdaad echt een blunder van de eerste orde.
Wel heel mooi dat de browsermakerS dit relatief snel aan hebben gepakt (en dus niet een beetje hebben zitten kijken voor een maand o.i.d)
Hoe zit het nou voor andere klanten van Diginotar? Die krijgen ineens rode tekentjes ipv een groen slotje in de browser? :X
Hoe zit het nou voor andere klanten van Diginotar? Die krijgen ineens rode tekentjes ipv een groen slotje in de browser?
Yup
Niet helemaal. Zoals in de teksat te lezen valt hebben ze bv DigID met een andere root-key getekend en dus zal die nog wel groen blijven.

Maar heel veel klanten worden hier dus wel door geraakt en die kunnen hun bezoekers dus geen garanties meer geven.
Volgensmij heeft diginotar het zelf nog niet helemaal begrepen. Mozilla, Google en MS blokkeren niet alleen de root van Diginotar, maar alle certificaten welke bevatten "CN=Diginotar "

Als je naar de intermediate van digid.nl kijkt, zul je zien dat deze daarmee ook begint. Digid.nl zal dus wel degelijk problemen krijgen zonder update.
Heb je hier een bron voor? Waarom zou met niet de CA revoken (wat een logische stap is) en in plaats daarvan naar de CN gaan kijken?
De overheid heeft zelf het stamcertificaat in handen (als Staat der Nederlanden Root CA ) dus daar zal vrij snel een oplossing voor getroffen moeten kunnen worden. Wat ik ervan begrijp is dat er sowieso meer partijen zijn (naast Diginotar) die vanuit dat stamcertificaat overheidscertificaten kunnen uitgeven.
Hier staan ze allemaal, en Diginotar staat er ook (nog) tussen:
http://www.logius.nl/prod...sluiten/toegetreden-csps/
Ja, die krijgen ze, en dat vechten die klanten wel uit met Diginotar. Als klant betaal je jaarlijks een fors bedrag voor SSL certificaten aan een partij die zogenaamd te vertrouwen is, als dat niet het geval blijkt te zijn worden die certificaten gewoon ergens anders gekocht en komt de rekening bij Diginotar op de mat.
Wel zal het bedrijf zal later op de dag met een verklaring komen.
Zouden ze dan echt gaan vertellen hoeveel geld ze van de Iraanse overheid hebben ontvangen :?

edit:
Oei, ik wordt weggemod, zou de geheime dienst me nu al op het spoor zijn :X Sorry jongens, zo bedoelde ik het niet hoor, ik bedoelde natuurlijk dat het goed zaken doen is met landen als Iran en dat corruptie daar nauwelijks voorkomt.

[Reactie gewijzigd door Gepetto op 30 augustus 2011 13:25]

Zouden ze ook zo snel een CA-root uit de browser te kieperen als het een bedrijf als VeriSign zou zijn?
Lijkt me niet, VeriSign is daar volgens mij veelte groot voor, denk dat een groot deel van beveiligde websites dan opeens een mooie foutmelding geven
Ik denk dat Verisign zich wel 2x bedenkt voordat ze dit soort praktijken uitvoeren. Als je ziet wat voor procedures je daar moet doen voor een SSL certificaatje en wat die dingen vervolgens kosten... voor dat geld hebben ze geen overheidssteun uit Iran nodig.

Daarnaast, stel Verisign zou dat wel doen, dan heeft dat meer gevolgen dan alleen een paar SSL certificaatjes. Verisign beheert ook een aantal TLDs die hun door de amerikaanse overheid zijn toegeschoven. Als bekend wordt dat Verisign ongeldige certificaten aan Iran uitdeelt zal het niet lang duren voordat de Amerikaanse overheid alle verantwoordelijkheden bij Verisign weg trekt.
VeriSign voert in principe dezelfde checks uit als Diginotar. Kwestie van een VeriSign Affiliate zoeken en of de verificatie te manipuleren is. Daar waar mensen werken worden fouten gemaakt. Bewust of onbewust.
Nope.
Ik zie in de Internet Properties -> Content -> Certificates -> Untrusted publishers 2 x een fraudulent Microsoft Corporation certificaat, uitgegeven door Verisign.
Daarnaast nog 9 uitgegeven door UTN-UserFirst-Hardware, voor onder andere ... mail.google.com!
Deze 11 certificaten zijn gewoon slechts ingetrokken (revoked), zonder de Versign of UserTrust root CA ongeldig te verklaren...
Tien jaar geleden gebeurde zoiets: Verisign gaf een nieuw Microsoft certificaat uit aan een derde partij, zie http://news.cnet.com/2100-1001-254586.html

Microsoft kwam er toen snel achter omdat de werkwijze van Verisign destijds anders was: als je namens een bedrijf een certificaat aanvraagt ging er een fax naar de directie van dat bedrijf (zoals bekend bij KvK), en daarin staan instructies om de uitgifte tegen te houden (niet veel meer dan het terugsturen van een fax). Microsoft deed dat toen, maar Verisign gaf toch het certificaat uit. Maar, destijds stuurde Verisign ook nog een bevestigingsfax naar de directie van Microsoft, welke vervolgens actie ondernam.

Door die laatste handeling kon het certificaat binnen enkele dagen na uitgifte worden ingetrokken. We zijn tien jaar verder en DigiNotar heeft twee maanden nodig - niet best.
Opvallend is dat het certificaat van Diginotar bijna twee maanden onopgemerkt is gebleven.
Dit vind ik toch wel zorgwekkend. Sowieso is het hele certificaat gebeuren voor de gebruiker lekker onduidelijk. Maar had wel gedacht en gehoopt dat de controle wat beter zou zijn dan twee maanden...
Misschien is het certificaat de eerste 2 maanden niet in gebruik geweest.

Google Chrome had om een of andere reden wel door dat er iets niet pluis was:
http://www.google.co.uk/s...read?tid=2da6158b094b225a

Doordat Chrome foutmeldingen gaf kwam men er vrij snel achter dat er gerommeld was met certificaten.
Google checkt de geldigheid van de certificaten op een andere plek als de andere browser, waarom dat precies verschil geeft weet ik niet, maar dat is waarom Chrome er niet in trapt en de andere wel...
Volgens mij checkt Chrome of de Google certificaten zijn uitgegeven door de certificatie partij waarmee Google zaken doet.
Een aanvullende non-standaard check die Chrome alleen kan doen omdat ze natuurlijk bij google zelf weten bij wie ze hun eigen certificaten hebben vastgelegd.
Wat ik trouwens wel mooi vind om te zien is dat Google, Microsoft en Mozilla in dit soort situaties de handen in één slaan en snel met een oplossing komen.
Ze moeten natuurlijk wel, maar uiteindelijk zat google door deze blunder in de problemen, netjes dat Microsoft en Mozilla meteen helpen.

edit: wat revivespirit hierboven eigenlijk zegt dus :)

[Reactie gewijzigd door Mr. Jinx op 30 augustus 2011 09:32]

Ik vraag me toch af waarom men zo stellig durft te zeggen dat dit geen impact zal hebben op het werk dat Diginotar voor de overheid doet, de kans is toch wel heel erg groot dat ook dit tussenliggend certificaat gecompromitteerd is.

Admin-edit:Link weggehaald. Dit valt onder spammen.

[Reactie gewijzigd door RoD op 30 augustus 2011 11:17]

Het lijkt me dat het samenhangt met het begrip root-cert. De root van PKI-overheid is de staat der Nederlanden, en niet Diginotar. DigiD en veel andere overheidssites gebruiken authenticatiemiddelen op basis van PKI-o.

@vanbroup, @Thralas: dank voor de aanvullingen.

30-8-2011 aanvulling:
Toch heftig, dit. Dit issue is voor Diginotar zo fundamenteel - het hele businessmodel draait op vertrouwen. Alles staat of valt met de kwaliteit van het uitmanagen van deze calamiteit door Diginotar.Ik ben benieuwd hoe ze dit op gaan pakken, samen met hun moederbedrijf Vasco. Gaat Vasco de in januari aangekochte dochter Diginotar laten vallen?

[Reactie gewijzigd door Batje4 op 30 augustus 2011 13:05]

Maar het is wel DigiNotar welke bepaalt welk certificaat wel of niet wordt uitgegeven op dit intermediate root.

Dus ondanks dat dit een ander root is, heeft DigiNotar wel degelijk de controle en is het gevaar dus even groot.
De testbuild voor Firefox blokkeert DigiNotar op basis van CN=DigiNotar* als issuer. Ook de intermediate CA onder Staat der Nederlanden valt dus hieronder, dat betekent uiteraard dat as.digid.nl (en co) een 'invalid certificate' warning geeft.
Dat noemde iemand op 1 van de comments in de [url= betreffende bug bij Mozilla en gaf daar een bijbehorende screenshot bij die in 1 van de tweakers.net artikelen wordt gebruikt. Inmiddels is de bug al geupdate met commentaar van iemand van Mozilla dat ze het niet op deze manier gaan doen. Alleen de root CA van DigiNotar zelf wordt geblokkeerd. Overige info gaat nog volgen:
The current patch we have checked in dis-trusts everything issued by the DigiNotar Root CA, but does not dis-trust certificates issued by DigiNotar as part of the Staat der Nederlanden PKI (PKIoverheid), which chain up to a different root.

Mozilla's reasons for making this distinction will be made clear soon.

Gerv
Daardoor zou in geval van Firefox dus ook geen rare dingen moeten gebeuren bij de sites van de overheid. Mocht je het niet met deze discussie eens zijn dan kun je dat natuurlijk in die bug onderbouwen (hoewel ze het waarschijnlijk liever in hun nieuwsgroep hebben, die is bedoeld voor discussie, niet de bugtracker).
volgens mij zijn updates nog niet uit... krijg nog geen melding van chrome ieder geval.
Over Googel chrome in menu.. dan krijg je chrome about scherm dat gelijk nieuwe updates doet..

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6DestinyAssassin's Creed UnityFIFA 15Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox OneMobiele besturingssystemen

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013