'Iran gebruikt Nederlands certificaat om Gmail te onderscheppen'
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.
Met 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.
Reacties (113)
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-
-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.
-edit-
Dit certificaat is echt. Je kan niet zomaar een certificaat faken en dit certificaat geeft aan dat het geldig is.waarvan de authenticiteit nog niet is bevestigd.
-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 maandag 29 augustus 2011 22:56]
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.
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 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.
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.Dat Diginotar het frauduleuze ssl-certificaat uitreikte, is opzienbarend: dit bedrijf doet veel werk voor de overheid...
(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".
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.
EDIT:
Discussie of ik doelde op C2000 of het P2000 netwerk is niet relevant.
[Reactie gewijzigd door Gepetto op dinsdag 30 augustus 2011 13:32]
Natuurlijk mag je er met een kritisch oog naar kijken. Sterker nog: 
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
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 dinsdag 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..
volgens mij heeft microsoft en mozilla dat nu dus wel gedaan.
http://www.microsoft.com/...ity/advisory/2607712.mspx
http://blog.mozilla.com/s...t-google-com-certificate/
http://www.microsoft.com/...ity/advisory/2607712.mspx
http://blog.mozilla.com/s...t-google-com-certificate/
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.
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.
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.
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.
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.
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.
Tuurlijk wel. Als de private key van het bedrijf openbaar is, kun je alles ondertekenen.Dit certificaat is echt. Je kan niet zomaar een certificaat faken en dit certificaat geeft aan dat het geldig is.
[Reactie gewijzigd door TD-er op maandag 29 augustus 2011 22:56]
Mja, zelfs cacert regelt dit soort dingen beter. 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.Lijkt me niet meer dan logisch dat zoiets gecontroleerd wordt.
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.
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.
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).
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.Definieer "volledig domeinnaam". "mailserver" is een geldig lokaal domein en SSL certificaten kunnen wel degelijk gebruikt worden op een lokaal netwerk.
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.
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.
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.Definieer "volledig domeinnaam". "mailserver" is een geldig lokaal domein en SSL certificaten kunnen wel degelijk gebruikt worden op een lokaal netwerk.
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.
Het is niet de Mozilla of welke andere browser partij maar de CA die een fout gemaakt heeft.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.
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.....
Dan moet alleen nog zoiets als DNSsec worden gebruikt om de DNS te checken en dan zit je volgens mij redelijk goed.....
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.
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.
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.
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.
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.
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.
Face it, je kunt niet zomaar een systeem waar miljarden op rekenen even weggooien en vervangen door iets anders.
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.Dit is het zoveelste bankroet van X.509, maar niemand wil het nog aangezien er te veel geld mee wordt verdient.
Face it, je kunt niet zomaar een systeem waar miljarden op rekenen even weggooien en vervangen door iets anders.
"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).
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.
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...
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...
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.
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.
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.
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?
Verder natuurlijk wel een kwalijke zaak dat Diginotar dat ssl-certificaat heeft uigereikt.
Is het lek inmiddels gedicht of wordt daar aan gewerkt?
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
In een certificaat staat waar je de authenticiteit kunt controleren.Wat wordt er bedoeld met dat Google Chrome het wel op de juiste plek controleert?
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.
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.
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.
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.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.
[Reactie gewijzigd door .oisyn op dinsdag 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
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
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
Waarschijnlijk maakt Google Chrome voor *.google.com gebruik van Strict-Transport-Security
Tja een foutje kan altijd, maar als je in principe niet meer kunt vertrouwen op een SSL certificaat dan weet ik het ook niet meer...
Zeer kwalijk dat privacy(slash levens) zo op het spel komen te staan! moet goed uitgezocht worden over wat en hoe en gelijk aanpakken mocht er iets niet in orde zijn.
Zoiets opmerken is een, het daadwerkelijk aanpakken van dit soort praktijken kan nog wel een paar jaar op zich laten wachten met de huidige beveiliging mentaliteit op het internet.
Dit lijkt mij een gevalletje 'zoveel mogelijk certificaten zo snel mogelijk verkopen, levert veel op'. Helaas is dit wat je krijgt als jan en alleman geld kan gaan verdienen met het uitgeven van certificaten.
Ik ben toch bang dat het anders is (op zijn minst was). Diginotar is ontstaan vanuit de notarissen van Nederland, en is altijd de door de overheid geprefereerde PKI leverancier geweest (geloof alleen dat in den beginne Pink Roccade een soortgelijke bevoegdheid had).
Geen idee of de overname door Vasco hierop van invloed is geweest, maar opvallend is het wel. Ik ben er nog niet uit wat nou erger is, een wellicht compleet gebrek aan controle bij diginotar, of een zeer geraffineerde hack / fraude van de Iraanse overheid.
Geen idee of de overname door Vasco hierop van invloed is geweest, maar opvallend is het wel. Ik ben er nog niet uit wat nou erger is, een wellicht compleet gebrek aan controle bij diginotar, of een zeer geraffineerde hack / fraude van de Iraanse overheid.
Dit is best zorgelijk. Als dit kan met een wildcard certificaat op het Google.com domein dan weet je nooit meer zeker of de groene balk veilig is.
Ik vraag mij ook af hoe het kan want er is toch wel een redelijk goede controle die dus niet lijkt te werken.
Ik vraag mij ook af hoe het kan want er is toch wel een redelijk goede controle die dus niet lijkt te werken.
Voor deze man-in-the-middle attack komt ook wel wat meer kijken dan alleen een certificaat aanvragen.Ik vraag mij ook af hoe het kan want er is toch wel een redelijk goede controle die dus niet lijkt te werken.
Je moet namelijk het verkeer onderscheppen, zodat ze via jouw servers werken.
Daarvoor moeten best wel veel partijen meewerken, wil je dat landelijk doen.
Al was het alleen al omdat dat best wel veel capaciteit kost in zowel bandbreedte als server-capaciteit en je moet de routing omleiden van een IP-range en/of de DNS-servers aanpassen van de grote ISP's.
Dat is geen probleem voor Iran aangezien ze al bezig waren met Iran-net en allang bekend is dat ook zij een great chinese firewall hebben.
Bevestigen is niet zo moeilijk. Er worden 2 certificaten getoond in de pastebin paste; een intermediary CA en een wildcard cerfiticaat voor *.google.comDat blijkt uit informatie die op Pastebin is gepubliceerd, maar waarvan de authenticiteit nog niet is bevestigd.
Als je bijvoorbeeld in Firefox kijkt zal je zien dat je een certificaat genaamd "DigiNotar Root CA" hebt (Onder Preferences -> Encryption -> View certificates -> Authorities) . De intermediary is door deze CA gesigned en het wildcardcertificaat weer door de intermediary. Deze certificaten zijn dus echt.
Als iemand deze heeft weten te 'faken' kunnen we die persoon meteen een nobel prijs in de categorie wiskunde geven....
Een intermediary CA kan prima de juiste plek zijn om een certificaat te controleren. Volgens mij (IRC alert...) heeft chrome echter de fingerprint ingebakken van google's SSL certificaat. Das eigenlijk valsspelen. Dat is net zoiets als het IP van je DNS name (google.com) inbakken in je browser zodat een DNS server het niet verkeerd kan afgeven.Google Chrome zou het ssl-certificaat wel op de 'juiste plek' controleren
[Reactie gewijzigd door JUDGExKTF op maandag 29 augustus 2011 23:06]
Ter bevestiging: het gebruikte intermediate CA is ook gewoon te downloaden op de website van Diginotar. http://www.diginotar.nl/K...en/tabid/308/Default.aspx en dan bij DigiNotar Public CA 2025.
In ieder geval kan je hiermee al verifieren dat Diginotar een certificaat heeft ondertekend voor *.google.com en dat Google zelf een andere CA gebruikt. Voor Gmail worden geen wildcard certificates gebruikt, maar mail.google.com certificaten.
Diginotar heeft hoe dan ook flink geblunderd: of ze hebben onterecht het valse wildcard certificaat ondertekend (hoe kan dat niet opvallen?) of de private key van een van hun CA's is gecompromitteerd. Allebei verdient het niet bepaald de schoonheidsprijs.
In ieder geval kan je hiermee al verifieren dat Diginotar een certificaat heeft ondertekend voor *.google.com en dat Google zelf een andere CA gebruikt. Voor Gmail worden geen wildcard certificates gebruikt, maar mail.google.com certificaten.
Diginotar heeft hoe dan ook flink geblunderd: of ze hebben onterecht het valse wildcard certificaat ondertekend (hoe kan dat niet opvallen?) of de private key van een van hun CA's is gecompromitteerd. Allebei verdient het niet bepaald de schoonheidsprijs.
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
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
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.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?
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.
Onderwerpen
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
