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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 113 reacties, 42.946 views •

De Iraanse overheid is in staat om verkeer van en naar de Gmail-servers te onderscheppen dankzij een ssl-certificaat dat door een Nederlandse ssl-autoriteit, DigiNotar, is uitgereikt. Dat blijkt uit informatie die op Pastebin is gepubliceerd.

Gebrek aan sslMet het ten onrechte uitgereikte ssl-certificaat van DigiNotar zou Iran een man in the middle-aanval op zijn inwoners kunnen uitvoeren, waarbij het land alle verkeer van en naar de servers van Gmail onderschept.

Argeloze internetgebruikers zouden daarvan niets merken, omdat het certificaat zou zijn ondertekend door een geldige certificaatautoriteit: DigiNotar. Dat blijkt uit informatie die op Pastebin is gepubliceerd.

Het betreffende ongeldige ssl-certificaat is geldig voor alle subdomeinen van Google.com en zou op 10 juli van dit jaar zijn verstrekt. Overigens is voor een man in the middle-aanval meer nodig dan alleen een vervalst ssl-certificaat: ook de verbinding tussen gebruiker en server moet kunnen worden gemanipuleerd.

Dat DigiNotar het frauduleuze ssl-certificaat uitreikte, is opzienbarend: dit bedrijf doet veel werk voor de overheid en zorgt bijvoorbeeld voor het ssl-certificaat van DigiD, evenals de ssl-certificaten die bedrijven en instellingen gebruiken om vertrouwelijk met overheidsdiensten te communiceren.

Volgens Webwereld waren niet alle Iraanse internetters vatbaar voor de man in the middle-aanval; Google Chrome zou het ssl-certificaat wel op de 'juiste plek' controleren. DigiNotar kon niet worden bereikt voor commentaar.

Update, 23:23: DigiNotar heeft het betwiste certificaat inmiddels ingetrokken.

Gerelateerde content

Alle gerelateerde content (39)

Reacties (113)

Reactiefilter:-11130107+166+222+32
Moderatie-faq Wijzig weergave
Dit soort bedrijven zouden geen SSL certificaten uit mogen geven. Ik hoop dat Microsoft, Apple, Mozilla en Opera (en evt. grote Linux distro's) dit bedrijf zo snel mogelijk uit hun "root CA"-lijsten halen.

-edit-
waarvan de authenticiteit nog niet is bevestigd.
Dit certificaat is echt. Je kan niet zomaar een certificaat faken en dit certificaat geeft aan dat het geldig is.

-edit2- @hieronder:
Het zou inderdaad kunnen dat er iets goed fout is gegaan bij Diginotar (bijv. private keys "gehackt" door Iraanse overheid?) en het lijkt me inderdaad erg goed om eerst te onderzoeken waar het fout is gegaan. Mocht dit echter opzettelijk zijn, zie hierboven. :)

[Reactie gewijzigd door TvdW op 29 augustus 2011 22:56]

Sorry, maar dit is gewoon weer het resultaat van een designfout in X.509 en kan alleen worden opgelost door X.509 gewoon geheel over boord te zetten. Verisign is al een paar keer betrapt op het uitgeven van certificaten voor de US-government voor domeinen waar die overheid geen eigen van was. Aan de andere kant zijn bedrijven verplicht om crypto-keys af te staan als daar een bevel voor is. Hier komt ook het zwakke punt van X.509, want er is niet een enkele root, maar iedereen kan zijn root-certificaat uitgeven en gewoon tweakers.net op https aanbieden bv. Het is alleen een kwestie van het root-certificaat te vertrouwen.

Bij Verisign is men bv zo slim geweest om een root-certificaat met MD2 hashing uit te geven in het verleden met een geldigheid waar we nog vele jaren plezier van gaan hebben. Hier is actieve image-replay mogelijk voor iedereen met te veel tijd. MD5 is voor partijen met voldoende belangen en geld ook binnen bereik aan het komen of is al zover.

Het punt is gewoon dat we van X.509 af moeten, maar helaas kunnen we voorlopig niet zonder aangezien er nog geen alternatief is. Een tussentijdse oplossing is bv om de fingerprints van je X.509 certificaat in DNSSEC op te nemen en de client dit te laten verifiŽren. De enige oplossing die zoiets heeft is OpenSSH voor SSH hostkeys waarbij het standaard uit staat aan de client kant. Ook laat de uitrol van DNSSEC flink op zich wachten en als we de overgang van A-records in DNS naar MX-records als maatstaf nemen dan zijn we nog wel even zoet. De implementatie van SRV-records is daar wel een ander mooi voorbeeld van.

Helaas zijn ook veel X.509 certificaten foutief uitgegeven, lees bijna allemaal aangezien ze allemaal de root-dot missen. Aan de andere kant gaat soms software stuk als je die root-dot toevoegt. Postfix is er een voorbeeld van die gewoon niet met "reject_rbl_client zen.spamhaus.org." kan omgaan terwijl dit wel een tripje langs alle search domains in je configuratie voorkomt. De rest van dit soort interpretatie uitdagingen moeten allemaal nog worden uitgezocht.

Maar om weer terug te komen op dit probleem. Dit is het zoveelste bankroet van X.509, maar niemand wil het nog aangezien er te veel geld mee wordt verdient. Aan de andere kant zijn de RFC's er al enige tijd om met behulp van OpenPGP-keys SSL-verbindingen op te zetten, maar niemand die de eerste stap zet en wel in het huidige model blijven geloven. Zeker zolang een SSL-reseller een verificatie stap doet met een mailtje naar bv hostmaster@ en niet beseffende dat die adressen niet altijd toebehoren aan wie men denkt.

Aan de andere kant is het wel grappig om te zien dat mensen zich zorgen maken dat Iran hun mailverkeer kan zien, maar niet stil staan bij het feit dat de US-government alle data van alle US-bedrijven mogen opvragen inclusief wat in de EU staat. Een heerlijke illusie en duidelijke prioriteitstelling als ik mag concluderen.
Dit is helemaal geen 'design' fout van X.509 maar een fout van de CA en van sommige applicaties die gebruik maken van SSL/TLS. Een vergelijkbaar probleem zou zich voordoen met OpenPGP keys als je niet elke website handmatig wil goedkeuren. Als je geen vertrouwen hebt in de CAs dan verwijder je toch gewoon alle root certificaten. Dan moet je per site zelf aangeven of je het SSL certificaat vertrouwd (als je tenminste een zinnige browser hebt).
Dit is een vaak gemaakte denkfout: technische en organisatorische zaken door elkaar te halen. X509 zorgt voor trust delegatie. In dit geval blijkt de Iraanse overheid net zo veel of weinig te vertrouwen als Diginotar. Dat is geen probleem in X509, dat is een probleem met de procedures bij Diginotar.

Hetzelfde kan gezegd worden van je Verisign MD2 certificaat. Als jij dat wil vertrouwen, dan accepteer jij daarmee de veiligheid van MD2. X509 verplicht je op geen enkele manier om een dergelijk zwak certificate te vetrouwen, en verstandige mensen doen dat ook niet.

OpenPGP heeft *exact* hetzelfde probleem. Je kunt signatures met andere signatures ondertekenen. Als je begint met 0 vertrouwde handtekeningen, dan kom je niet verder dan 0, en als je begint met gecorrumpeerde handtekeningen dan zijn de daarmee ondertekende handtekeningen ook niet te vertrouwen.
Helaas is het geen denkfout hoor, het is een designfout alleen het duurt even voordat mensen het door hebben en dat komt hoe X.509 werk, maar ik zal het anders beschrijven. Bij de ontwikkeling is uitgegaan van het feit dat er een enkele centrale autoriteit zou zijn die certificaten zou uitgeven en de enige hiŽrarchie die erin zit is een root-certificaat en onderliggende certificaten om het even makkelijk te maken. Er is nooit nagedacht waar deze certificaten voor worden ingezet.

Nu even naar DNS wat redelijk vergelijkbaar is. Eigenlijk moet je het meer vergelijken met de hosts-file, maar DNS werkt overal omdat er een enkele root-zone is. Alternatieve root-zones komen niet echt van de grond en dat is maar goed ook, maar hoe zou DNS werken als we 142 root-zones zouden hebben en 10 daarvan hebben tweakers.net opgenomen en allemaal met verschillende informatie. Welke moet je vertrouwen? We houden nu een hosts file bij van vele certificaten die mogelijk dingen kunnen tekenen.

Hoe waanzinnig dit ook klinkt, we doen dit wel met X.509 en we vertrouwen erop CA's certificaten dubbel niet uitgeven. Niets, maar dan ook helemaal niets in X.509 zorgt ervoor dat je dit kan voorkomen. X.509 wordt bijna alleen nog maar ingezet voor client en server authenticatie, maar je kan alles invullen. Als jij dus client-authenticatie doet met X.509 kan elk certificaat naar binnen als die maar de juist naam en signature heeft om het simpel te zeggen. (er zitten nog een paar details aan)

X.509 heeft om in jou termen te blijven alleen een organisatorische en financiŽle hiŽrarchie. Er is niets wat de technische kant afdwingt en dat is iets wat bij DNSSEC gelukkig beter is aangepakt. Het systeem is niet waterdicht, want in theorie kan iemand in de root-zone bv nog steeds tweakers.net andere keys geven, maar het valt meer op. DLV is hier een implementatie van trouwens.

Maar is de Iraanse overheid te vertrouwen? Net zoveel als elke andere overheid, alleen Iran werd deze keer gesnapt. Is Diginotar te vertrouwen? Nee, het is een bedrijf en daarmee verplicht om zijn crypto-keys ten alle tijden af te geven aan de overheid en aangezien Diginotar eigenlijk VASCO is dan heeft de US-overheid ook per direct toegang tot die keys. Zijn de procedures bij Diginotar in orde? Ja en nee. Hoe kan je controleren dat een naam al niet is geregistreerd in een van de andere 141 certificaten in Firefox bv? In je eigen namespace controleren gaat nog wel, maar alle andere? En dan nog alle andere andere waar je heb bestaan niet van weet.

Zijn CA's onverantwoordelijk? Ja, met een geldigheidsduur van 30 jaar om certificaten te maken en valideren is totaal onverantwoordelijk. Het is ruim buiten alles wat bewezen is en om die dingen in 2006 nog aan te maken net het MD2-incident is gewoon niet goed te praten. Gelukkig zijn er andere die een korte periode aan houden en 12 a 13 jaar lijkt steeds meer de norm te gaan worden.

Zijn gebruikers onverantwoordelijk? Ja, maar welke andere keuze hebben ze? Veel is gewoon slecht geÔmplementeerd en laat veel te wensen over. Hier is gewoon nog veel werkt te verzetten in zowel beheer, ontwikkeling, als interface design. En dat zijn geen dingen die je oplost met een procedure bij een CA.
Ook al zijn ze verplicht de keys af te staan. Ze hebben niet de private key van de domein houder. Ze zouden een trusted alternatief kunnen maken maar de oorspronkelijk geencrypte data is nog steeds niet te unencrypten.
Een hele boel woorden maar je hebt nog steeds niet aangegeven wat nou de "design fout" is en je hebt al helemaal niet aangegeven wat het alternatief is. OpenPGP? leg maar eens uit waarom "web of trust" beter is dan een hierarchisch model. En dan bedoel ik niet technisch gezien maar gezien vanuit de onwetende gebruiker.
Welk onderdeel begrijp je niet? Het deel van dat elke gek een certificaat voor tweakers.net kan maken en met een extra certificaat valide kan laten lijken? Of het onderdeel dat je geen state of authority kan vaststellen als gebruiker. Of dat er niet hiŽrarchisch is aan X.509 behalve de financiŽle afdracht?

Zoals al eerder gezegd. Pas het X.509 design eens toe op DNS en introduceer eens zeg 142 root-zones ipv 1 met soms een namespace collision. Dus via drie paden kom je uit bij tweakers.net maar welke is de goede? Dit is nu wat gebeurt bij X.509. Er zijn totaal geen enkele beperking voor bv Verisign of Comodo om certificaten voor bv postbank.nl en postbank.de aan de te maken en iedereen zegt "thumbs up" want Verisign zegt dat het goed is. Intussen zit je op de website van Boris Boef je gegeven in te vullen en pas bij het ontbreken van de TAN-code SMS begin je misschien achterdocht te krijgen.

Dit is domweg een designfout en er is te veel gekeken naar hoe identiteitsbewijzen werken en werden uitgegeven in de jaren '80. En daar worden nog steeds te veel fouten gemaakt en grove fouten ook. De beste manier om aan een identiteit te komen tegenwoordig is om de interne post van een gemeente een ongeluk te laten krijgen en als hem als brave burger te helpen in zijn benarde situatie.

Zoals recentelijk nog bij Mozilla dat men certificaten vond die ze niet konden thuis brengen. En hier stel jij daadwerkelijk je vertrouwen in? Willekeurige bitjes op een disk die veiligheid moeten brengen? Ik dacht het niet. Die hoeveelheid bitjes moet terug naar iets wat behapbaar is en wat bv in TPM past of op die manier kan worden beveiligd. Daarna wil ik de fingerprint van het certificaat/key bij de eigenaar van het domein kunnen controleren.

Dit zou een mooie tussentijdse oplossing zijn en de grap is. De resource records voor DNS bestaan al enige tijd voor SSH hostkeys, OpenPGP en X.509. Met de komst van DNSSEC kan je het antwoord valideren dat het van de goede partij vandaan komt. Zorg dat de applicaties deze RFC's ook implementeren en je komt een redelijk eind. Het maakt dan niet meer uit of het certificaat met OpenPGP, door Verisign of door jezelf is ondertekend. Je kan controleren dat het certificaat bij die dienst hoort en dat is waar het om gaat.

Het is allemaal om je risico footprint beheersbaar te maken en te houden. Het risico nu is gewoon te groot aan het worden en na 23 jaar is het een keer mooi geweest. Een mooi voorbeeld als afsluiter is bv DKIM wat het bovenstaande al gebruikt en eigenlijk DNSSEC nog verplicht moet stellen. Dus ja er zijn werkbare alternatieve, maar er zit te veel geld in voor CA's en ontwikkelaars om het probleem goed aan te pakken, want dat is de kip met de gouden eieren slachten.
Dat is geen designfout maar een designkeuze. Onderdeel van X.509 is dat je zelf kan beslissen wie je vertrouwt. Als jij Verisign niet vertrouwd, dan verwijder je hem uit de lijst van trusted certificates in je browser en maakt het helemaal niks meer uit. Het probleem hier is dat de gemiddelde gebruiker het technische verhaal helemaal niks boeit en dus gewoon z'n browsermaker volgt. Vandaar dat Mozilla e.d. nu een grote verantwoordelijkheid hebben, waar ze goed mee om lijken te gaan gezien het feit dat ze meteen de CA's verwijderen.

Het leuke is bovendien dat OpenPGP op exact dezelfde manier werkt, alleen jij dat wel een goed alternatief vindt. Wat is het verschil tussen de werking van OpenPGP en X.509? OpenPGP gaat ook uit van signatures op een key om aan te geven dat hij vertrouwd is.

Dat jij geen vertrouwen hebt in het distributed systeem is heel wat anders. Al zouden we 1 centrale organisatie hebben die certificaten uitgeeft levert dat ook weer allemaal problemen met zich mee. Het is de introductie van de single-point-of-failure, een hack heeft veel grotere gevolgen en je kan niet meer selectief bedrijven vertrouwen. Jouw voorstel om de resource records in DNSSec te zetten is niet een verandering van techniek of filosofie, maar puur een verplaatsing van verantwoordelijkheid. Je geeft de registrars die de domeinzones onderhouden de verantwoordelijkheid om te checken ipv aparte CA's.

Verder is je verhaal dat je niet kan checken of een andere CA al een certificaat voor hetzelfde domein heeft uitgegeven onzin. Dat is namelijk iets wat helemaal niet nodig. Als je meerdere certificaten voor hetzelfde domein uitgeeft is dat helemaal geen probleem. Ik zou het juist als een voordeel zien op een moment dat een certificaat door meerdere CA's is gesignd. Je komt pas in de problemen als zoals nu een CA niet te vertrouwen is, maar dat probleem is niet te omzeilen. Je kan het hoogstens verplaatsen.
Tjonge jonge, wat zie jij de wereld pessimistisch.
Dit is het zoveelste bankroet van X.509, maar niemand wil het nog aangezien er te veel geld mee wordt verdient.
Eh, en aangezien het een godsvermogen zou kosten om bestaande infrastructuur en een aantal miljard systemen te upgraden om met iets nieuws te werken. En je kunt niet om dubbele infrastructuur heen, aangezien veel systemen niet kunnen worden geŁpgraded.

Face it, je kunt niet zomaar een systeem waar miljarden op rekenen even weggooien en vervangen door iets anders.
Laatst was er ook een onderzoek dat liet zien dat er best wel veel certificaten uitgegeven waren voor niet volledige domeinnamen, zoals 'mailserver'.
Ook een kwalijke zaak.

Certificaten zouden als extra check een entry in de DNS moeten hebben en alleen valid mogen zijn voor volledige domeinnamen.

Verder is het inderdaad kwalijk dat certificaten uitgegeven kunnen worden aan mensen die niet de eigenaar zijn van het domein.
Dit certificaat is echt. Je kan niet zomaar een certificaat faken en dit certificaat geeft aan dat het geldig is.
Tuurlijk wel. Als de private key van het bedrijf openbaar is, kun je alles ondertekenen.

[Reactie gewijzigd door TD-er op 29 augustus 2011 22:56]

Definieer "volledig domeinnaam". "mailserver" is een geldig lokaal domein en SSL certificaten kunnen wel degelijk gebruikt worden op een lokaal netwerk.

SSL is gebaseerd op de "Chain of trust". Jij vertrouwt je browser, je browser vertrouwt enkele roots, die weer enkele resellers vertrouwen en die weer de klanten vertrouwen (etc). Al deze partijen moeten zorgen dat hun onderliggende certificaten geen ongeldige domeinen bevatten. Een reseller (of CA, etc) moet dus altijd controleren of het domeinnaam wel ťcht bij de klant hoort, en of het domein wel in de "root namespace" ligt (dus de .com, .net, etc domeinen. .local en "mailserver" horen hier dus niet bij).

Dit systeem werkt in principe perfect - totdat een bedrijf als Mozilla (die toonaangevend is op gebied van de acceptatie van SSL roots) een fout maakt en een bedrijf ten onrechte als betrouwbaar markeert. Het kan ook fout gaan als een van de resellers (of de CA zelf) niet goed controleert op bovenstaande voorwaarden.
Definieer "volledig domeinnaam". "mailserver" is een geldig lokaal domein en SSL certificaten kunnen wel degelijk gebruikt worden op een lokaal netwerk.
mailserver is geen FQDN dit zou nooit geaccepteerd mogen worden door een CA. Puur omdat dit certificaat zal werken voor mailserver van welk bedrijf dan ook.

het gebruik van mailserver is sowieso niet handig je kunt het beste altijd FQDN gebruiken. Dus bijvoorbeeld mailserver.intra.<domainname> dan heb je geen probleem als je met mailserver van een externe partij via bijvoorbeeld een VPN moet praten.

Daarbij is het verkwistend om een certificaat aan te vragen voor een interne server. Aangezien er alleen interne mensen naartoe kunnen, kun je er veel beter voor zorgen dat je het certificaat standaard installeert op de systemen.
Dit systeem werkt in principe perfect - totdat een bedrijf als Mozilla (die toonaangevend is op gebied van de acceptatie van SSL roots) een fout maakt en een bedrijf ten onrechte als betrouwbaar markeert.
Het is niet de Mozilla of welke andere browser partij maar de CA die een fout gemaakt heeft.

Ik heb het gevoel dat et hele SSL CA principe niet (meer) werkt. Puur omdat er veel te veel partijen komen die CA zijn.
nieuws: Opnieuw Comodo-reseller gehackt
nieuws: Comodo geeft frauduleuze ssl-certificaten uit na hack

IMO zou het meer moeten werken op een vergelijkbare manier als DNS. Er zou IMO een centrale root CA moeten zijn die door verwijst naar sub CA's met records die een relatief korte TTL hebben. Dan zal het centraal geregeld worden i.p.v. via de browsers.
Tevens zou een certificaat ongeacht de geldigheidsduur toch nog via de sub CA geverifieerd moeten worden, zodat er ongeldige of revokte certificaten delete kunnen worden. Zoals het gmail certificaat.
ik zeg, certificaten laten lopen via SIDN (voor NL) en je registrar, dan kan in de DNS ook een verwijzing naar je certificaat worden opgenomen.

Dan moet alleen nog zoiets als DNSsec worden gebruikt om de DNS te checken en dan zit je volgens mij redelijk goed.....
Definieer "volledig domeinnaam". "mailserver" is een geldig lokaal domein en SSL certificaten kunnen wel degelijk gebruikt worden op een lokaal netwerk.
Een van de uitgangspunten van DNS is dat domeinen uniek zijn en dat elk 'onderdeel' van een FQDN een uniek SOA (Start Of Authority) heeft.
Zo is er een SOA voor een toplevel domain (.NL, .COM) en heeft een domein ook 1 SOA (google.com, tweakers.nl).
Dus nee, "mailserver" is geen geldig domein. Dat je het in een afgesloten systeem (LAN, WAN) wel kan gebruiken is in dit opzicht eerder een vervelend side-effect dan een onderdeel van DNS.

Daarnaast is het zo, zoals je zelf al zegt, een Chain of trust.
Dus in dat afgesloten interne netwerk, waar die Chain of trust verondersteld mag worden, kun je prima terecht met self-signed certificates.
Met een goed ingerichte PKI kun je (ook onder Windows) prima bedrijfscertificaten uitgeven en de CA root certificate inlezen op alle workstations.
Geen probleem en geen vervelende popups bij gebruikers.

Dus een officiele CA als Diginotar mag nooit een certificaat uitgeven voor mailserver of elke andere naam die niet uniek is.
com, nl, be, ... zijn ook domeinen (top level domain). Sinds kort mag iedereen een tld aanvragen dus ja 'mailserver' kan een tld zijn, en dus een geldig domein.

Hoe de regels van ssl zijn weet ik niet, maar als je voor alle subdomeinen van google.com een certificaat kan aanvragen, zie ik niet in waarom je niet voor alle subdomeinen van com of van nl of 'mailserver' een certificaat kan aanvragen. Puur theoretisch zou het kunnen. Er kan eventueel gespecifieerd kunnen zijn dat een bepaald level nodig is, dat kan ik niet zeggen.

Of het een goed idee is om een certificaat af te leveren voor een tld is een ander verhaal.
Dat is irrelevant. Een CA hoort te checken of jij daadwerkelijk eigenaar bent van de FQDN. Niet alleen is "mailserver" geen FQDN, maar je kunt ook nooit aantonen dat je er de eigenaar van bent. Zelfs als het een TLD zou zijn, dan nog is het geen FQDN, en kun je als bedrijf er geen volledig eigenaar van zijn.
Ik denk dat hij met volledige domainnaam FQDN bedoeld, dus een Full Qualified Domain Name (dus host+domain+TLD) TLD=Top-Level-Domain (zoals .com .net .org .nl).
Mja, zelfs cacert regelt dit soort dingen beter. Lijkt me niet meer dan logisch dat zoiets gecontroleerd wordt.
Lijkt me niet meer dan logisch dat zoiets gecontroleerd wordt.
Zoals al meer gezegd, is hier best wel veel werk verricht, dus controles omzeilen is dan niet zo veel werk in vergelijking met de rest.
In het artikel staat ook dat dit bedrijf het ssl-certificaat regelt van DigiD en andere overheidszaken. Lijkt me niet heel praktisch dus om dat te gaan blokkeren. Ik zou eerst ff uitzoeken wat er fout is gegaan bij Diginotar voordat je zulke drastische maatregelen gaat treffen.
Het zal best dat het onpraktisch is als hier in NL DigiD plat gaat. Maar dat certificaat uitgegeven door Diginotar wordt/werd in Iran actief gebruikt in een MITM attack. In Iran kan het vrij dodelijk (letterlijk!) zijn als de verkeerde mensen je email lezen. Me dunkt dat in dit geval de maatregelen niet snel te drastisch zijn.

Daar komt bij dat niemand blijkbaar weet hoe die certificaten aangemaakt zijn, en het dus niet uitgesloten is dat iemand de private keys voor de Digid website heeft, of in staat is om een nieuw certificaat voor de Digid website aan te maken. Het is te verdedigen dat er momenteel reden is om Digid niet te vertrouwen.
Ze hebben dus niet heel dignotar geblokkeerd maar ze hebben het rootcert van dignotar uit hun trusted list gegooid. Dat is iets minder drastisch dan te zeggen dat je nooit meer iets van dignotar vertrouwt.
Eh?

Enig idee van hoe certificaten werken? Als je het CA certificaat uit je lijst met vertrouwde root certificaten haalt, wat nu dus is gebeurd, is zeggen dat je ze niet meer vertrouwd precies wat je doet.

Browsers zonder het CA certificaat van Diginotar in hun lijst zullen geen enkel certificaat dat door diginotar getekend is vertrouwen.
Eruit gooien is een brug tever. Diginotar dwingen om alle keys gesigneerd met hun huidige rootcert laten revoken lijkt me slechts logisch.

Dat is veel werk, en levert nadelen op voor hun klanten. Het systeem ondergraven levert nog veel meer nadelen op voor veel meer mensen. Een ketting is zo zwak als de zwakste schakel, het Diginotar rootcert is hier de zwakke schakel.
Dat Diginotar het frauduleuze ssl-certificaat uitreikte, is opzienbarend: dit bedrijf doet veel werk voor de overheid...
Dan is het toch juist niet opzienbarend. De NL overheid doet bij voorkeur zaken met bedrijven die nogal eens wat steken laten vallen. Denk maar aan het bedrijf dat de paspoorten maakte, die achteraf gemakkelijk te vervalsen waren, of recentelijk het bedrijf dat de OV chipkaarten heeft gemaakt met gebruik van een chip waarvan al lang bekend was dat deze gekraakt was. En dan hebben we het maar niet over de miljoenen die over de balk zijn gegooid bij het falende P2000 systeem van politie en brandweer en veel mislukte ICT projecten bij lokale overheden.

(Riep er nou iemand iets over een te duur systeem van tolpoortjes voor het rekeningrijden?)
Man hou toch eens op met modder gooien. Zo gemakkelijk om oude koeien uit de sloot te blijven halen.
Natuurlijk gaat er welk eens iets fout bij de overheid, ook daar werken mensen. Ook in andere bedrijven gaan projecten fout, of lopen zwaar uit de kosten. Daarin staat de overheid echt niet alleen. Van die andere zaken hoor je het echter niet, en van de overheid wel.

Overigens is Diginotar niet de enige CSP voor PKIoverheid. En zelfs Verisign heeft wel eens een steekje laten vallen met het uitgeven van valse certificaten voor de "Microsoft Corporation".
Dit is geen modder gooien, dit gaat om geld wat Nederlandse burgers met hun belastinggeld bij elkaar hebben gebracht en daarom mag je er best kritisch naar kijken indien dit geld op een verkeerde manier wordt besteed. Bovendien zijn het geen oude koeien, maar een aantal recente voorbeelden die nu nog steeds niet zijn opgelost, maar wel nog steeds handen vol geld kosten. Gemeenschapsgeld wel te verstaan.

EDIT:

Discussie of ik doelde op C2000 of het P2000 netwerk is niet relevant.

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

Natuurlijk mag je er met een kritisch oog naar kijken. Sterker nog: d:)b

En ja, er worden vaak slechte beslissingen genomen (OV chipkaart moest goedkoper, C2000 mag van de gemeentes niet meer palen plaatsen om de dekking te verbeteren)

Maar om te zeggen dat de NL overheid bij voorkeur zaken doet met bedrijven die 'wat steken laten vallen' is gewoon onzin.

Hoe dan ook, deze discussie kunnen we wel verderzetten, maar dat is offtopic in deze context :)

[Reactie gewijzigd door Equator op 30 augustus 2011 09:54]

In engeland hebben ze zon mooi pasjes systeem. Waarom moeten wij nederlands dan het wiel opnieuw uitvinden.. (en dat ook slecht doen) i.p.v. een werkend systeem overnemen..
"Dit soort bedrijven zouden geen SSL certificaten uit mogen geven."

Is een beetje kort door de bocht. De vraag is hoe Iran het certificaat in handen heeft gekregen. Voor hetzelfde geld hebben ze bij een Google medewerker of een schoonmaker bij DigiNotar een zak geld hebben neergezet.

Het hele bedrijf van deCA-lijsten halen is ook niet handig; een heel leger semi-overheidsinstanties werken met deze certificaten. Om te beginnen dat notarissen ineens niet meer bij deze diensten kunnen, met alle gevolgen van dien voor hun werkzaamheden (erfrecht, hypotheken etc).
Maakt niet uit. Ik heb voor ons bedrijf een (code signing) certificate aangevraagd. Zelfs dat certificate staat (1) niet op het netwerk en is (2) beveiligd met een password wat maar twee medewerkers kennen. De CA heeft bij onze board gecontroleerd of ik bevoegd was. Het diginotar root certificate zou beter beveiligd moeten zijn dan dat (op z'n minst dubbel passwoord, niemand die in z'n eentje certificates kan uitgeven). Een schoonmaker zou er dus nooit bij moeten kunnen. En DigiNotar had bij de CEO van Google zelf moeten checken of deze aanvraag correct was.
Daar waar jij het over hebt bepaald de aanvrager van het certificaat. Meer controles resulteert in een duurder certificaat. Het is nog altijd de eindgebruiker die moet controleren of de uitgever van het certificaat te vertrouwen is en om te controleren welke validaties deze heeft toegepast.

Simpele vergelijking is als jij geld krijgt van iemand en dit zou via een tussenpersoon gaan dan controleer je ook wie dit is als JIJ garant moet staan dat het geld bij jou terecht moet komen. Dan zeg je ook niet geef het geld maar aan de eerste de beste persoon die je tegenkomt want ik neem de gok dat het wel bij me aankomt.
ja, liever dat je nog een man-in-the-middle-attack hebt met diginotar dan dat je een melding krijgt dat het certificaat niet klopt natuurlijk....

want een week niet bij die diensten kunnen omdat er nog een nieuw certificaat moet worden uitgegeven is natuurlijk veel nadeliger dan dat erfrecht, hypotheken e.d. helemaal open staan...

En als uitkomt dat dit via de schoonmaker is gebeurd dan mag vind ik dat alle schade op DigiNotar verhaald mag/moet worden, en dit bedrijf nooit meer vertrouwd wordt..
zoals MSalters hierboven al zegt, bij een certificaat van/voor google.com (of facebook, yahoo, microsoft, abnamro etc. etc.) moet je natuurlijk EXTRA opletten, en dan is het een kleine moeite om even bij Google te checken of ze inderdaad naar jou willen overstappen voor hun certificaten...
Inmiddels heeft Mozilla laten weten een update te zullen uitbrengen voor oa. Firefox, om de root CA van Diginotar te verwijderen.

Grote vraag is of Mozilla ook het 'DigiNotar PKIoverheid CA Overheid en Bedrijven'-certificaat (een tweede CA, signed door Staat der Nederlanden CA) blacklist. In dat geval hebben overheidswebsites (oa. Digid) een probleempje..
Ze gaan alle certificaten met CN="DigiNotar *" blacklisten, dus de overheid is ook de sjaak ben ik bang.
Daar zat ik dus ook al aan te denken.
Moxie Marlinspike had afgelopen defcon een aardig alternatief voor het huidige CA systeem gepresenteerd en een firefox plugin daarvoor uitgebracht.

Binnen dit systeem wordt de geldigheid van een certficaat geverifieerd via zogenaamde notaries. De client doet dit dus niet meer rechtstreeks. Je kan in deze plugin instellen bij hoeveel notaries het certificaat gelijk moet zijn voordat de client deze pas vertrouwt.

artikel ca alternatieven
perspectives

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

Ik snap niet wat Iran hier mee te maken heeft. Ik heb nog helemaal niets gezien wat erop wijst dan Iran hier ook maar iets mee te maken heeft.
Verschillende serieuze nieuwsbronnen bevestigen wat al een tijdje een gerucht was op Iraanse fora, namelijk dat de Iraanse overheid middels dit certificaat zich kon voordoen als een onderdeel van Google. De Iraanse overheid heeft blijkbaar al het dataverkeer van Iraanse inwoners met Google (o.a. Gmail) onderschept.
Kun je je voorstellen hoeveel mensen aan de hand van die informatie zijn verdwenen?

Dit bedrijf heeft dus ůf actief meegewerkt aan zeer kwalijke zaken van het Iraanse regime of de certificering die o.a. ook voor DigiD wordt gebruikt is zo lek als een mandje. Er is geen optie 3. Welke optie het ook is, iedereen gaat zich vandaag van dit bedrijf distantiŽren.

Lees maar wat meer berichten en luister naar een goede toelichting op BNR, dit is echte een groot probleem.
Dit probleem kan zich niet bij zo makkelijk bij de certificering van digid voordoen, omdat het certificaat gecheckt wordt bij servers van de overheid. en zoals een tweaker hierboven al aangaf, om zo'n certificaat te verkrijgen moet je wel het eea regelen..
Ik hoop dat er wel meer gevolgen voor het bedrijf zullen zijn dan dat de klanten zich van het bedrijf distantiŽren.

Ik hoop dat op zijn minst de directeur en de medewerker (dader) in kwestie vervolgd zullen worden voor dood door schuld. Dat zijn we de slachtoffers wel verschuldigd.
Ik mag hopen dat het daarbij niet blijft. Iran staat op de VN sanctielijst. Cryptografische systemen en onderdelen daarvan mogen niet naar Iran geexporteerd worden. Handtekeningen worden daarbij met name genoemd. Dat valt formeel onder de categorie "wapens". Kortom, gezien de hudige regels moet Diginotar vervolgd worden wegens illegale wapenexport naar Iran.
Verschillende serieuze nieuwsbronnen bevestigen wat al een tijdje een gerucht was op Iraanse fora, namelijk dat de Iraanse overheid middels dit certificaat zich kon voordoen als een onderdeel van Google. De Iraanse overheid heeft blijkbaar al het dataverkeer van Iraanse inwoners met Google (o.a. Gmail) onderschept.
Kun je je voorstellen hoeveel mensen aan de hand van die informatie zijn verdwenen?

Dit bedrijf heeft dus ůf actief meegewerkt aan zeer kwalijke zaken van het Iraanse regime of de certificering die o.a. ook voor DigiD wordt gebruikt is zo lek als een mandje. Er is geen optie 3. Welke optie het ook is, iedereen gaat zich vandaag van dit bedrijf distantiŽren.

Lees maar wat meer berichten en luister naar een goede toelichting op BNR, dit is echte een groot probleem.
Ik begrijp het probleem wel (en met name de ernst hiervan), alleen de beschuldiging richting Iran zonder een enkele vorm van bewijs (en het vervolgens overnemen van deze berichtgeven door tal van websites) is telegraaf-journalistiek.

Als dat bewijs bestaat, moet het toch op z'n minst getoond worden. Anders is het geen journalistiek meer, maar zijn het roddels. Kan jij me dat bewijs laten zien?
Hoe had je dat bewijs voor je gezien? Een bekentenis van het staatshoofd / hoofd van de geheime dienst van Iran?
In een democratie is het al lastig genoeg om de overheid te controleren (hoe weten we zeker dat de AIVD niet net zo hard meeleest met Nederlandse GMail-gebruikers; ze mogen het niet, maar ik zou er niet blind op durven vertrouwen dat ze het niet kunnen / doen). Niet dat ik ooit een Iraans wetboek heb gezien, maar ik betwijfel of ze een tegenhander van onze Wet Openbaarheid Bestuur hebben.
Het IAEA heeft meer dan genoeg moeite om in de gaten te houden of ze kernwapens (proberen te) maken, en jij wilt een servertje opsporen dat werkelijk overal kan staan?

Ik vind het prima als je erop staat dat berichtgeving hierover woorden als "vermoedelijk" gebruikt om aan te geven dat er geen zekerheid bestaat, maar het stil houden totdat die zekerheid er is lijkt me geen optie.
True, uit niets blijkt dat dit specifiek over Iran gaat. Maar de kans is groot dat een eindgebruiker dit heeft ontdekt en deze info met de wereld deelt. Ik snap best dat deze gebruiker graag zijn identiteit geheim houd als het een inwoner van Iran is.

Hopelijk geeft Diginotar op een later moment opheldering over de aanvraag zodat de partij die hier fraude met eventueel dodelijke afloop pleegt wordt gevonden. Indien het om een lek gaat bij Diginotar dan zal dit waarschijnlijk nooit worden opgelost.

Totaal terecht dus dat Diginotar op de blacklist komt tot er duidelijkheid is aangezien dit niet wenselijk is.
TRue, een trol, niet geverifieerd en ongedefineerd. Maar wellicht wel genoeg reden om Iran binnen te vallen. Slechte journalistiek. Ik vraag me af aan wie Diginotar het uiteindelijk certificaat gestuurd heeft. Dat moet te achterhalen zijn.


maar als dit artikel het sluitend bewijs moet leveren voor deze daad: http://www.f-secure.com/weblog/archives/00002228.html dan denk ik nog dat je redelijk simpel bent. IN zoverrre, als je besluit te stelen lijkt het me niet raadzaak je visitekaartje achter te laten.

INdeze artikel worden de hacks toegeschreven aan iraanse hacker groepen, omdat men een bericht heeft achtergelaten ondertekend met iraanse hacker.
DUH

[Reactie gewijzigd door flossed op 30 augustus 2011 19:36]

Wat wordt er bedoeld met dat Google Chrome het wel op de juiste plek controleert?
Verder natuurlijk wel een kwalijke zaak dat Diginotar dat ssl-certificaat heeft uigereikt.
Is het lek inmiddels gedicht of wordt daar aan gewerkt?
Google Chrome keurt bij *.google.com enkel certificaten van bepaalde CA's goed. Als het geen certificaat is dat getekend is door Verisign, Equifax, GeoTrust of Googles eigen CA dan gaat de browser piepen. Zie: http://www.imperialviolet.org/2011/05/04/pinning.html
Het certificaat is ingetrokken.

Als je echter als overheid (Iran) de mogelijkheid hebt om het DNS om te leiden, dan kun je ook alle verzoeken voor de CRL (Certificate Revocation List) van Diginotar omleiden.
De gebruiker krijgt dan een CRL terug waarop dit certificaat niet genoemd staat en de browserv vertrouwd dan dus gewoon het certificaat.

Dus het lek is niet te dichten omdat het lek ook bestaat uit DNS controle.
Als je echter als overheid (Iran) de mogelijkheid hebt om het DNS om te leiden, dan kun je ook alle verzoeken voor de CRL (Certificate Revocation List) van Diginotar omleiden.
Nonsens natuurlijk, daarvoor is communicatie met de CA vereist, wat een secure verbinding is met een certificaat die gekoppeld is aan die CA. Iran kan dat certificaat niet faken (ze hebben de private key niet), dus ze kunnen ook geen aangepaste CRL publishen.

[Reactie gewijzigd door .oisyn op 30 augustus 2011 02:33]

Je hebt helemaal gelijk.
Ondanks het late uur zat je beter op te letten dan ik.

Maar de conclusie blijft staan.
In plats van een eigen CRL te publiceren, dat inderdaad niet kan, kan Iran nog steeds via DNS de requests voor deze CRL blokkeren dan wel omleiden naar een blackhole.
Zodra de browser geen response krijgt gaat deze er van uit dat alles oke is en wordt het certificaat dus toch vertrouwd.

https://community.emc.com...ificate-validation-issues
waarschijnlijk dat chrome de bedrijfseigen SSL-certificaten voor google rechtstreeks bij google zelf gaat controleren en niet bij diginotar. Dat op zich is natuurlijk ook al fout, want zo proberen ze heel het certificaat-gebeuren te omzeilen. Ik kan me niet inbeelden dat zij op de een of andere briljante manier er in zouden slagen om frauduleuze geldige certificaten van alle domeinen te traceren, terwijl alle andere browsermakers hier niet in slagen om ze te detecteren
Wat wordt er bedoeld met dat Google Chrome het wel op de juiste plek controleert?
In een certificaat staat waar je de authenticiteit kunt controleren.
Maar als je browser 'toevallig' al weet waar de domeinnamen van Google hun certificaten vandaan halen dan kun je natuurlijk als browser ook alarm slaan wanneer die certificaten van die domeinen ineens ergens anders ondertekend zijn.
Waarschijnlijk maakt Google Chrome voor *.google.com gebruik van Strict-Transport-Security
Ik snap niet dat diginotar dit certificaat nog niet ingetrokken heeft , op hun website staat toch duidelijk.
Een SSL Servercertificaat wordt hiermee een belangrijk instrument in het
tegengaan van internetfraude en “phishing” waarbij men zich ten onrechte
voordoet als een website van een vertrouwede organisatie om
gemakkelijk uw identiteitsgegevens, creditcardnummers of wachtwoord te ontfutselen.
bron: http://www.diginotar.nl/P...en/tabid/248/Default.aspx

Duidelijk toch dat er een soort “phishing” word gepleegd als er data word onderschept , als bedrijf zou ik toch echt elke stap ondernemen om dit soort “phishing” tegen te gaan.

Misschien loopt dit certificaat onder Verisign en zou makkelijk geblokkeerd kunnen worden.
Het certificaat is wel revoked:

Reason: unspecified
Revocation Time: Aug 29 16:59:03 2011 GMT


Twee uurtjes erbij (want GMT) maakt Aug 29 18:59:03 2011
Ja, maar bij diginotar is iedereen naar huis, het is namelijk wel een 36 urige werkweek. Dus als CNET belt omdat je de Iraanse overheid van virtuele munitie voorziet, dan hoor je gewoon een bandje:

"The certificate was issued by DigiNotar, based in the Netherlands. Representatives from the company did not immediately respond to an e-mail seeking comment today and an automated message said the offices were closed for the night and offered no voice-mail option. A phone call and e-mail to Vasco Data Security, parent company of DigiNotar, were not immediately returned."

bron
Volgens mij kunnen alleen browsers/os'en het betreffende certificaat op een 'revoke list' zetten, of de CA in zijn geheel verwijderen (iets minder waarschijnlijk).
Diginotar kan wel een verzoek sturen naar alle browsers/leveranciers die hun CA hebben geinstalleerd met het verzoek dit te doen, maar dat is ook alles. En aangezien ik verwacht dat die het nieuws ook wel strak in de gaten houden over dit onderwerp, verwacht ik dat dat niet meer nodig zal zijn.
Zal de medewerker bij DigiNotarecht niet opgevallen zijn dat het een wildcard certificaat was voor Google? Google vraagt een certificaat voor hun hele domein aan in Nederland terwijl het het een Amerikaans bedrijf is.

Is het verder niet vreemd dat er geen check is of er al een certificaat bestaat voor het *.google.com en hoelang die nog geldig. Er moet toch in het verlenen van certificaten een controle bestaan of er voor het specifieke domein al een certificaat bestaat!?!?

Als men een e-mail programma gebruikt i.p.v. de webmail van Google dan wordt een andere domeinnaam gebruikt namelijk googlemail.com
SSL certificaten uitgeven is bulk draaien. Er worden een aantal zaken met de hand geverifieerd en als je weet hoe dat die checks exact verlopen, dan zijn er wegen om daar omheen te gaan.

Stel dat ik als BlaTieBla B.V. een SSL certificaat aanvraag voor *.tweakers.net doe, dan wordt er bij de KvK gekeken wie of wat het bedrijf is. Daarnaast wordt in de Whois database gekeken wie eigenaar van het domein is. Daaruit blijkt dat BlaTieBla B.V. geen relatie heeft met Tweakers.net. Gevolg ik krijg geen certificaat op basis van die gegevens.

Nu komt het veel voor dat bedrijven de IT-beslommeringen uitbesteden en in dergelijke constructies is het heel gewoon dat andere partijen dus certificaten aanvragen. Echter moet dit goedgekeurd worden door de eigenaar van het domein. En dat laatste gebeurd in veel gevallen per fax.......

Een tweede verificatie wordt ook nog gedaan per telefoon (afhankelijk van het type certificaat). Ook daar zijn wegen omheen (doorschakelingen e.d.). Officieel moet er via de receptie van het bedrijf met de persoon in kwestie contact worden gezocht, maar dat is ook niet altijd haalbaar.

Zo'n uitgifte proces is nu eenmaal niet waterdicht te maken. Zelfs als je de aanvrager / eigenaar langs laat komen met een paspoort is er nog de kans dat je twee personen aan de balie krijgt met valse identiteitspapieren.

Daarnaast het je ook te maken met verouderde Whois database informatie, waardoor de originele contactpersonen niet meer werkzaam zijn in die functie of binnen het bedrijf. In dat geval is het kiezen of delen; poot stijf houden en geen certificaat uitgeven of de regels een beetje buigen naar aanleiding van een zielig verhaal en hopen dat Tweakers.net een vaste klant wordt en dus een oogje dichtknijpen voor deze ene keer.

Nu het certificaat is ingetrokken zou het probleem binnen 24 verholpen moeten zijn (tenzij ze standaard OCSP gebruiken, dan is het nml real-time). Immers hoort in een x509-complaint omgeving (lees: browser e.d.) een CRL geraadpleegd te worden. Probleem is dat de oudere OS'en en browsers de CRL check op SSL-certificaten vaak uit hebben staan.....
Nou kiest de nederlandse overheid zelfs de verkeerde certificaten boer xD

Maar vind het wel slecht geregeld, hoe kan ieder ssl-boer een certificaat maken voor ieder domein??
Hier moet meer regeling in komen, zoals dat de NS, portnl en KPN (o.a.) gewon weer van de overheid moet zijn.
Kan niet - je moet als CA een ellendig lang proces door om een root CA in een browser/OS te krijgen. Vziw is Diginotar een root CA die dit proces door heeft gelopen (http://www.mozilla.org/projects/security/certs/policy/ bijvoorbeeld) en dat maakt dit juist nog erger.
Diginotar is geen root CA! De Nederlandse Staat is zelf een root CA, DigiNotar B.V. zit daar tussen als intermediate CA. In feite zou de Nederlandse Staat DigiNotar (en al hun klanten) kunnen straffen door het intermediate certificaat in te trekken. Daarmee zou alles wat DigiNotar uitgeeft aan certificaten (met terugwerkende kracht) ongeldig zijn.
ehm, volgens mij is Diginotar gewoon een root CA.
Daarnaast heb je ook nog Diginotar PKI Overheid wat een root CA is voor certificaten voor (semi-) overheden en bedrijven die zaken (willen) doen met overheden.

Certificaten die met dat root certificate zijn ondertekent zouden door de Nederlandse staat ongeldig gemaakt kunnen worden, maar de 'eigen' certificaten van Diginotar staan daar los van.
Het ťťn sluit het ander niet uit. Je loopt een certificate chain af totdat je een certificate tegenkomt die in je CA lijst staat. Diginotar heeft een certificate wat ondertekend is door Staat der Nederlanden CA, maar blijkbaar ook zonder die verdere ondertekeining door browsers als root certificate werd geaccepteerd.
Verrek, jij gaat rap. Een artikel over SSL certificaten en jij zit in 3 zinnen al weer op het onderwerp van deprivatisering.
Stel er werkt een externe bij DigiNotar (ja... tuurlijk hoort deze man/vrouw geen toegang te hebben tot alles... maar dat heeft hij/zij nou net wel... en dat beseft hij/zij ook).

De persoon in kwestie weet dat 'ie gevoelige data kan inzien/kopieŽren en doet dat ook. Vervolgens maakt 'ie er een Business Case bij: "Ik verkoop het aan de Iraanse overheid".
Er wordt geld gestort op een zwiterse bank rekening. De externe zit netjes zijn contract uit en gaat daarna weg... niemand heeft iets door.

* Die externe kan iedereen zijn, een DBA'er.. een slimme Cisco man (aftappen van onbeveiligd verkeer)... een Backup operator.. of gewoon iemand van 'de afdeling IT'.
En misschien is het allemaal wel met voorbedachte rade gedaan,. en heeft de Iraanse overheid wel iemand van de HR afdeling van Diginotar een kaartje voor een WK-wedstrijd gegeven om een 'foute' externe naar binnen te helpen...


Als de private Key inderdaad is gestolen (misschien weet Diginotar dit niet eens of komt ze er nooit achter), dan kan men echt vrijwel alles in Nederland.

- Zo wisselen energiemaatschappijen bijvoorbeeld 'energie/meter' gegevens met elkaar uit dankzij een certificaat van Diginotar (client authentication).
- DigID
- Werken bijna alle overheden wel ergens met certificaten van Diginotar (denk ook aan het Kadaster, wat het gebruikt om 'graafberichten' uit te wisselen).
"In een reactie zegt Frank Wassenaar van het Ministerie van Binnenlandse Zaken zich geen zorgen te maken over de gevolgen voor DigiD. "Wij hebben geen enkele twijfel aan de beveiliging van DigiD naar aanleiding van dit nieuws", zegt hij tegenover NU.nl.

Gescheiden traject

Hij benadrukt dat certificaten voor de Staat der Nederlanden via een gescheiden traject los van de andere certificaten worden gemaakt. "De hoofdsleutel ligt dan ook bij DigiD in de kluis en niet bij Diginotar."

http://www.nu.nl/internet...ering-tapte-gmail-af.html
Check Chrome certificaten dan op een andere of extra manier?
of heeft chroom extra regels voor google certificaten waarbij ze precies weten werk certificaat erbij hoort?

Iin ieder geval een gigantisch domper, ben wel benieuwd hoe dit kan gebereuren.

Overigens verwacht ik wel dat er een DNS hack bij hoort hoewel dat ik zulke landen als overheid zijnde niet zo moeilijk is denk ik
Check Chrome certificaten dan op een andere of extra manier?
of heeft chroom extra regels voor google certificaten waarbij ze precies weten werk certificaat erbij hoort?
Ik ben er niet zeker van maar ik vermoed dat het geen toeval is dat Google's browser niet om de tuin te leiden was bij het bezoeken van een MitM'ed Google website.
Chrome heeft simpelweg google's eigen certificaten ingebakken, terwijl Mozilla/de rest het op de normale manier controleert. Het is dus min of meer toeval dat het goed gaat met chrome, als dit van hotmail.com was geweest had chrome het ook fout gedaan.

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True