Comodo geeft frauduleuze ssl-certificaten uit na hack
Comodo heeft frauduleuze ssl-certificaten uitgegeven voor domeinen van Google, Yahoo, Mozilla en Microsoft, waardoor aanvallers de mogelijkheid hadden om zich als die bedrijven voor te doen. Mogelijk zitten Iraanse hackers achter de aanval.
Volgens Comodo, een bedrijf dat zich richt op computerveiligheid, hebben aanvallers op 15 maart toegang gekregen tot de account van een root-authority. Daarmee konden valse ssl-certificaten worden uitgevaardigd. Dat gebeurde negen keer, voor zeven verschillende domeinen. Het ging daarbij onder meer om Google.com, Gmail, de add-ons-website van Mozilla en de loginpagina's van Windows Live, Skype en Yahoo.
Comodo claimt dat de ssl-certificaten niet daadwerkelijk zijn gebruikt. De aanvallers hadden de ssl-certificaten echter eenvoudig kunnen gebruiken om man in the middle-aanvallen uit te voeren, waarbij de valse certificaten gebruikers ervan hadden kunnen overtuigen dat het om een legitieme website ging. Daarvoor was het noodzakelijk geweest om verkeer dat voor de desbetreffende domeinen was bestemd, door te leiden naar een andere server, bijvoorbeeld door dns cache poisoning.
Volgens Comodo was de aanval terug te leiden tot Iran. Een mogelijke verklaring is dat de Iraanse overheid de certificaten wilde gebruiken om toegang te krijgen tot e-mailaccounts van zijn bevolking. De overheid zou waarschijnlijk eenvoudig toegang kunnen krijgen tot de dns-servers van de Iraanse internetproviders, waarna verkeer naar een Iraanse overheidssite kan worden omgeleid.
Comodo stelt dat de certificaten zijn ingetrokken en Mozilla, Google en Microsoft hebben aangekondigd de certificaten in hun browsers te zullen blokkeren. Tor-ontwikkelaar Jacob Appelbaum wijst er echter op dat het proces van het intrekken van certificaten niet waterdicht is.
Het is niet de eerste keer dat Comodo valse ssl-certificaten uitgeeft. In december 2008 werd al eens een vals certificaat voor Mozilla.com uitgevaardigd door een Comodo-reseller. In 2005 gebeurde iets vergelijkbaars, waarbij onduidelijk is om welke domeinen het ging.
Reacties (48)
In feite zijn certificaten dus helemaal niet (meer) betrouwbaar. Tijd voor iets beters.
Certificaten zijn *ALTIJD* betrouwbaar. Het gaat erom of je de 'trusted third party' zoals Comodo nog vertrouwd.
Veel browsers vinden self signed anders niet betrouwbaar.
Maar ik vind dat Olaf gelijk heeft, die certificaten zijn dus niet betrouwbaar want ze zijn vals.
Ik vind het hele certificaat principe sowieso maar een beetje schijn veiligheid. Ze zijn belachelijk duur en alleen omdat er de naam van een bedrijf dat ze uitvaardigd op staat zou de website die je bezoekt veilig zijn???
Zo zie je maar als de zogenaamde authority zijn zaakjes niet op orde heeft is het geheel al niets meer waard.
Het zijn niet de kleine partijtjes die hier worden vervalst.
Maar ik vind dat Olaf gelijk heeft, die certificaten zijn dus niet betrouwbaar want ze zijn vals.
Ik vind het hele certificaat principe sowieso maar een beetje schijn veiligheid. Ze zijn belachelijk duur en alleen omdat er de naam van een bedrijf dat ze uitvaardigd op staat zou de website die je bezoekt veilig zijn???
Zo zie je maar als de zogenaamde authority zijn zaakjes niet op orde heeft is het geheel al niets meer waard.
Het zijn niet de kleine partijtjes die hier worden vervalst.
tenzij jij aangeeft dat je browser dat cert moet vertrouwen. genoeg bedrijven die hun eigen self-signed Root-CA hebben voor intern gebruik.Veel browsers vinden self signed anders niet betrouwbaar.
Klopt, gewoon je eigen gemaakte certificaat uitrollen naar de gebruikers.[...]
tenzij jij aangeeft dat je browser dat cert moet vertrouwen. genoeg bedrijven die hun eigen self-signed Root-CA hebben voor intern gebruik.
Als bedrijf zijnde vertrouw je uiteraard niemand behalve jezelf.
+ het is gratis en je hoeft niet op een certificaat te wachten
Niemand vertrouwen behalve jezelf is geen oplossing.
Microsoft bijv. gaat echt niet het certificaatje gebruiken dat door jouw CA getekend is (afgezien van het feit dat er per domein maar 1 kunnen gebruiken en het dus erg moeilijk zou worden als ieder groot bedrijf dergelijke eisen ging stellen).
Alle certificaten goedkeuren is ook niet echt een oplossing. Meeste bedrijven hebben toch aardig wat SSL websites nodig.
Microsoft bijv. gaat echt niet het certificaatje gebruiken dat door jouw CA getekend is (afgezien van het feit dat er per domein maar 1 kunnen gebruiken en het dus erg moeilijk zou worden als ieder groot bedrijf dergelijke eisen ging stellen).
Alle certificaten goedkeuren is ook niet echt een oplossing. Meeste bedrijven hebben toch aardig wat SSL websites nodig.
Duh. Als jij met een eigengemaakt paspoort aankomt bij Schiphol geloven we je ook niet.Veel browsers vinden self signed anders niet betrouwbaar.
Same thing.
Als jij een Cert van een trusted CA gebruikt betekent het alleen maar dat je de identiteit van betreffende site vertrouwt , meer niet.Ik vind het hele certificaat principe sowieso maar een beetje schijn veiligheid. Ze zijn belachelijk duur en alleen omdat er de naam van een bedrijf dat ze uitvaardigd op staat zou de website die je bezoekt veilig zijn???
De veiligheid van de site zelf heeft helemaal niks te maken met de CA of de aanwezigheid van een server certificate - het is echt alleen maar identificatie. Die site kan nog steeds zo lek als een zeef zijn.
[Reactie gewijzigd door alt-92 op 24 maart 2011 10:21]
Ik doel ook op het bericht van Niemand_Anders. Hij zegt dat certificaten altijd betrouwbaar zijn.
En ik was misschien wat onduidelijk met mijn "veilig zijn". Ik doel daar inderdaad mee op de identiteit.
Maar die identificatie vind ik dus waardeloos. Je vraagt aan een of ander bedrijf dat je niet kent of deze site inderdaad de site is die hij zegt te zijn en op basis daarvan vertrouw je dan maar jou informatie aan deze site.
Ik geef toe dat ik ook niet 123 een beter systeem weet, maar misschien is het beter dat er zoiets als een RIR ofzo voor komt.
En ik was misschien wat onduidelijk met mijn "veilig zijn". Ik doel daar inderdaad mee op de identiteit.
Maar die identificatie vind ik dus waardeloos. Je vraagt aan een of ander bedrijf dat je niet kent of deze site inderdaad de site is die hij zegt te zijn en op basis daarvan vertrouw je dan maar jou informatie aan deze site.
Ik geef toe dat ik ook niet 123 een beter systeem weet, maar misschien is het beter dat er zoiets als een RIR ofzo voor komt.
En wat is dan het verschil met een RIR (3rd party) en een CA (3rd party)?
Als het goed is moeten de CA's aardig wat bewijzen overleggen van veiligheid e.d. voordat hun certificaten opgenomen worden in bijv. windows of firefox. Als het certificaat daarin niet is opgenomen, worden de getekende certificaten door de betreffende CA ook niet vertrouwd.
Als het goed is moeten de CA's aardig wat bewijzen overleggen van veiligheid e.d. voordat hun certificaten opgenomen worden in bijv. windows of firefox. Als het certificaat daarin niet is opgenomen, worden de getekende certificaten door de betreffende CA ook niet vertrouwd.
wat is belachelijk duur, voor nog geen 15,00 heb je al een certificaat voor een jaar.
15 euro? Waar? Goedkoopste die ik ken zit rond de 20-25 euro.
Wel 1 van een CA die nagenoeg overal in zit uiteraard. Heb niks aan een door een CA getekend certificaat als bijv. mobieltjes hem niet vertrouwen. Dat is wel degelijk iets om rekening mee te houden.
Wel 1 van een CA die nagenoeg overal in zit uiteraard. Heb niks aan een door een CA getekend certificaat als bijv. mobieltjes hem niet vertrouwen. Dat is wel degelijk iets om rekening mee te houden.
startcom heeft zelfs gratis certificaten 
http://cert.startcom.org/
Is opgericht door Eddy Nigg, die een certificaat op mozilla.com heeft gekregen waar in dit bericht over gesproken wordt.
Weet niet of dit door alle browsers vertrouwd wordt, had dit een paar jaar geleden geprobeerd en werkte toen in elk geval erg goed. Het is sowieso handig als je er even mee wil experimenteren.
http://cert.startcom.org/
Is opgericht door Eddy Nigg, die een certificaat op mozilla.com heeft gekregen waar in dit bericht over gesproken wordt.
Weet niet of dit door alle browsers vertrouwd wordt, had dit een paar jaar geleden geprobeerd en werkte toen in elk geval erg goed. Het is sowieso handig als je er even mee wil experimenteren.
Ik vraag me af hoe hij de identiteit van de aanvrager voor dat geld of gratis kan valideren.
Onzin! Self signed certificaten zijn per definitie onbetrouwbaar. Eventueel in combinatie met DNS SEC kan je dit nog rechtbreien, maar dat is niet wat je hier stelt.
Nou, de Comodo SSL certificaten vonden de meeste webbrowsers toch al niet veilig, op Chrome en Firefox kreeg ik elke keer de melding van dat het SSL-certificaat niet in orde is bij alle website die SSL certificaten van Comodo hebben 
.
.
Same here.
Geloof dat comodo toch al een beetje uit de gratie is bij de browser makers....wel lullig als je er een certificaat hebt gekocht....
Geloof dat comodo toch al een beetje uit de gratie is bij de browser makers....wel lullig als je er een certificaat hebt gekocht....
Ik vind dat ze dan een niet-goed-geld-terug garantie moeten geven zodat Google etc. ergens anders een certificaat kunnen halen.
Ik wil niet zeggen dat Comodo goede diensten levert, maar het kan ook zeer vaak misgaan bij de website houder zelf ivm:
- verlopen certificaat gebruiken
- niet bruikbaar voor die website
- verkeerde bitjes aan en uitgezet tijdens de bestelling van het certificaat
Tja...
- verlopen certificaat gebruiken
- niet bruikbaar voor die website
- verkeerde bitjes aan en uitgezet tijdens de bestelling van het certificaat
Tja...
Verzin jij het? Dit is in feite het aloude "Quis custodiet ipsos custodes?" dilemma. Turtles watchmen all the way down.
[Reactie gewijzigd door Dreamvoid op 24 maart 2011 10:09]
Kan er ooit iets waterdichts worden ontwikkeld voor de hele wereldbevolking? Ik denk het niet, maar verbeter mij gerust.
Het principe van certificaten komt zeer dichtbij, want er is 1 organisatie die een root-certificaat heeft en van daaruit worden een aantal andere certificaten gegenereerd die op hun beurt ook weer certificaten kunnen aanmaken.
Een gesloten ketting met relatief weinig authoriteiten (lees: schakels) => weinig kans op een breach van de veiligheid.
En als de veiligheid toch zou gecompromitteerd worden, dan kan een certificaat en alle afgeleiden daarvan worden ingetrokken...
Laatst echter kwam ik in de settings van mijn browser de setting tegen 'check for revoked certificates' (oid), en tot mijn grote verbazing staat dat standaard uitgevinkt. Dat lijkt mij de grootste onveiligheid van het hele systeem te zijn. Opnieuw dus ligt de grootste verantwoordelijkheid bij de eindgebruiker...
Het principe van certificaten komt zeer dichtbij, want er is 1 organisatie die een root-certificaat heeft en van daaruit worden een aantal andere certificaten gegenereerd die op hun beurt ook weer certificaten kunnen aanmaken.
Een gesloten ketting met relatief weinig authoriteiten (lees: schakels) => weinig kans op een breach van de veiligheid.
En als de veiligheid toch zou gecompromitteerd worden, dan kan een certificaat en alle afgeleiden daarvan worden ingetrokken...
Laatst echter kwam ik in de settings van mijn browser de setting tegen 'check for revoked certificates' (oid), en tot mijn grote verbazing staat dat standaard uitgevinkt. Dat lijkt mij de grootste onveiligheid van het hele systeem te zijn. Opnieuw dus ligt de grootste verantwoordelijkheid bij de eindgebruiker...
In dit geval heeft de persoon die de root-certificaten beheerd het verprutst. Wat doe je in zo'n situatie?
Ik vind het jammer dat CRL/OSCP checks uit staan standaard. Dat is een belachelijke slechte actie en trapt het hele model onderuit. Zeker als je nog kan kiezen om toch nog door te gaan willens-en-wetens ondanks ongeldig certificaat. Dat kan anders en maar het is niet gunstig voor de business van de website en ook niet van de browser (als een andere browser hier relaxder mee omgaat).
Ik vind het jammer dat CRL/OSCP checks uit staan standaard. Dat is een belachelijke slechte actie en trapt het hele model onderuit. Zeker als je nog kan kiezen om toch nog door te gaan willens-en-wetens ondanks ongeldig certificaat. Dat kan anders en maar het is niet gunstig voor de business van de website en ook niet van de browser (als een andere browser hier relaxder mee omgaat).
Dit is heel fout...
Als Comodo inderdaad z'n beveiliging zo slecht op orde heeft dat men van buiten toegang heeft gekregen tot de systemen die certificaten genereren, dan zouden ze zich diep moeten gaan schamen.
Zodra certificaten niet meer te vertrouwen zijn valt de beveiliging van een groot deel van het internet om. Is de hotmail site wel degene die je denkt dat het is, of via DNS poisoning toch stiekem een ander? Waar het 'slotje' vroeger uitsluitsel gaf, zou dat na deze Comodo hack dus niet meer zo zijn...
Merk op dat je vaker dan je denkt te maken hebt met sites uit minder democratische regimes. Bit.ly is dan welliswaar Amerikaans, maar als de Lybische overheid het wil dan gaat 'ie op zwart - of word je omgeleid naar een site van een ander...
Als Comodo inderdaad z'n beveiliging zo slecht op orde heeft dat men van buiten toegang heeft gekregen tot de systemen die certificaten genereren, dan zouden ze zich diep moeten gaan schamen.
Zodra certificaten niet meer te vertrouwen zijn valt de beveiliging van een groot deel van het internet om. Is de hotmail site wel degene die je denkt dat het is, of via DNS poisoning toch stiekem een ander? Waar het 'slotje' vroeger uitsluitsel gaf, zou dat na deze Comodo hack dus niet meer zo zijn...
Merk op dat je vaker dan je denkt te maken hebt met sites uit minder democratische regimes. Bit.ly is dan welliswaar Amerikaans, maar als de Lybische overheid het wil dan gaat 'ie op zwart - of word je omgeleid naar een site van een ander...
[Reactie gewijzigd door Tukkertje-RaH op 24 maart 2011 10:06]
Gevalletje bestaansrecht verloren lijkt me, en alle dingen die geen 'purpose' meer hebben worden deleted tochAls Comodo inderdaad z'n beveiliging zo slecht op orde heeft dat men van buiten toegang heeft gekregen tot de systemen die certificaten genereren, dan zouden ze zich diep moeten gaan schamen.
.
Ah, daarom bracht Mozilla dus Firefox 3.6.16 uit
[Reactie gewijzigd door BčR op 24 maart 2011 10:06]
En is dit bericht pas uitgekomen na de lancering van Firefox 4.
En daarom had windows afgelopen week opeens een update van de certs: om deze certificaten expliciet te blacklisten.
Het is leuk dat een kleine selectie van TLS clients die certificaten blokeren. Maar TLS wordt voor meer dingen gebruikt dan alleen een handje vol webbrowsers.
Blind vertrouwen op de geldigheid van X.509 certificaten is gevaarlijk. Dit incident toont maar weer eens aan dat een selfsigned certificaat net zo betrouwbaar is als een die van de grote CAs af komt.
Het is sterk aan te raden om een plugin zoals Certificate Patrol ( https://addons.mozilla.or...addon/certificate-patrol/ ) te installeren zodat je weet als er aan de gang is met een certificaat van een website.
Certificaten zijn zoals keurmerken, je moet ze niet blind vertrouwen.
Blind vertrouwen op de geldigheid van X.509 certificaten is gevaarlijk. Dit incident toont maar weer eens aan dat een selfsigned certificaat net zo betrouwbaar is als een die van de grote CAs af komt.
Het is sterk aan te raden om een plugin zoals Certificate Patrol ( https://addons.mozilla.or...addon/certificate-patrol/ ) te installeren zodat je weet als er aan de gang is met een certificaat van een website.
Certificaten zijn zoals keurmerken, je moet ze niet blind vertrouwen.
[Reactie gewijzigd door elmuerte op 24 maart 2011 10:13]
Leuke opmerking maar dit is enkel vanuit technisch oogpunt relevant. Voor dit probleem moet gewoon een veilige standaard zijn, de addon die je aanhaalt is enkel te gebruiken voor mensen die materiedeskundig zijn. En hoewel dat voor jou en mij (deels) geld is dit voor 99% van de mensen niet het geval en die zul je dan ook in bescherming moeten nemen.
Een voorbeeld:
Als je slager bent moet je ook aan allerlei regels voldoen en komt de VWA langs om dit soort dingen te controleren (of het zou zo moeten werken natuurlijk). Ik ben in deze niet materiedeskundig en ben dan ook blij met het feit dat deze kwaliteitscontrole me uit handen wordt genomen.
En zo kan ik nog duizenden voorbeelden opnoemen, simpel afschuiven op 'certificaten zijn zoals keurmerken' vindt ik wat kort door de bocht.
Een voorbeeld:
Als je slager bent moet je ook aan allerlei regels voldoen en komt de VWA langs om dit soort dingen te controleren (of het zou zo moeten werken natuurlijk). Ik ben in deze niet materiedeskundig en ben dan ook blij met het feit dat deze kwaliteitscontrole me uit handen wordt genomen.
En zo kan ik nog duizenden voorbeelden opnoemen, simpel afschuiven op 'certificaten zijn zoals keurmerken' vindt ik wat kort door de bocht.
Want? Producten die geen "milieukeermerk" hebben worden bestempeld als slecht voor het milieu, ook al is dat misschien niet zo. Websites die een self-signed certificate hebben worden bestempeld als gevaarlijk.En zo kan ik nog duizenden voorbeelden opnoemen, simpel afschuiven op 'certificaten zijn zoals keurmerken' vindt ik wat kort door de bocht.
Het feit dat er een stempel "ok" op het product staat betekend niet dat het ok is, het is misplaatst vertrouwen in een symbool.
Een leuk voorbeeld is het merkje "CE" wat je op veel producten ziet. Veel mensen denken dat het apparaat gekeurd is oid. Maar "CE" vereist geen keuring, geen controle, etc. Het zegt niks over de betrouwbaarheid/kwaliteit van het product.
X.509 certificaten zijn nog erger, omdat het gepresenteerd wordt als een systeem voor identificatie, terwijl het eigenlijk niks anders is dan een key voor versleutelde communicatie is, en niet een betrouwbaar identificatie middel. De zogenoemde EV Certificaten zouden dat probleem oplossen, maar het enige wat het doet is de financiële drempel hoger leggen.
Als je identificatie verificatie aan X.509 certificaten wilt toevoegen moet je dat doen door middel van een web of trust, en niet door een simpele tree zoals het nu is.
Blijkbaar heb je X.509 certificaten niet helemaal begrepen. Zie RFC3280, en vooral de nieuwere RFC 5280 voor informatie hierover. Het is bedoelt om identificatie van een entiteit (persoon of service) te bewerkstelligen met een trusted third party. De beveiligde communicatie wordt gedaan met een session key, wanneer de identiteit van de service en eventueel ook de client is vastgesteld en de challenge/response heeft doorstaan.
EV is een hack. Het laat de CA harder rennen om eens wel te checken wie achter het eigenaarschap zit van een certificaat. Dat is iets dat ze in de eerste plaats hadden moeten doen, ipv een signing policy en bitje in je X.509 certificaat toevoegen zodat je groene browser balken ziet ipv blauwe. Dat kost absurt veel meer.
EV is een hack. Het laat de CA harder rennen om eens wel te checken wie achter het eigenaarschap zit van een certificaat. Dat is iets dat ze in de eerste plaats hadden moeten doen, ipv een signing policy en bitje in je X.509 certificaat toevoegen zodat je groene browser balken ziet ipv blauwe. Dat kost absurt veel meer.
Ik kreeg gisteren al een update van windows voor dit probleem. Zie ook :
http://support.microsoft.com/kb/2524375
http://support.microsoft.com/kb/2524375
En welke impact heeft / of kan dit mogelijk hebben op vb. Smartphones (ik denk specifiek aan Android, maar ook andere phones de vb. Gmail aankunnen), of WP7 (Live)
Of andere OS'en: Apple, Linux...
Krijgen die dan ook een certificate update ? (of beter gezegd certificate-revoke)
Of andere OS'en: Apple, Linux...
Krijgen die dan ook een certificate update ? (of beter gezegd certificate-revoke)
Iran kan zijn DNS servers rerouten naar een ander IP, en een gmail clone nabouwen, in de URL staat dan gewoon gmail.com, en het certificaat ziet er ook groen uit (dus valide). Mensen proberen in te loggen, gegevens worden gelogd, mensen van de overheid gaan dan hun mail lezen en arresteren die persoon mocht deze betrekkingen hebben tot opstanden.
Iran maakt gewoon een proxy die jou doorverbind naar de echte site en ziet al je verkeer. Ssl eraf,opslaan en in de achtergrond weer door naar de echte server. apache mod proxy doet niet veel anders. Weekje werk (mits je certificaat goed is)
Enlighten me, SSL eraf?
Smartphones kijken van oudsher niet naar CRLs of OSCP. Dus forget it. Dat wordt niet snel beter. Ik hoop dat ze het in Android, iPhone en WP gaan doen nu. Al is het wel weer extra verkeer over je data kanalen heen en je zuur betaalde UMTS.
En verder: zie humburg.
In Iran, en ook Afrika en de rest van Azie is de hoeveelheid telefoons hoger dan laptops. Dus je pakt hiermee nog steeds prima je doelgroep door een SSL stripping proxy die op 10GbE alles kan verwerken in hardware middels de gegenereerde certificaten.
En verder: zie humburg.
In Iran, en ook Afrika en de rest van Azie is de hoeveelheid telefoons hoger dan laptops. Dus je pakt hiermee nog steeds prima je doelgroep door een SSL stripping proxy die op 10GbE alles kan verwerken in hardware middels de gegenereerde certificaten.
Ik vind de reactie van Comodo wat vreemd:
Trouwens, ze worden geblokkeerd door Mozilla, Google en Microsoft, maar dat is ook weer niet waterdicht en heeft dus een browser-update nodig. Dat dit soort dingen zo kunnen gebeuren en vervolgens pas na veel moeite weer recht gezet kunnen worden, is zeer vreemd, en misschien moeten we inderdaad maar gaan nadenken over een alternatief/verbeterde versie (al zou ik nu niet weten hoe).
Dat is een beetje raar, want op hun website staat 'Not seen live on the internet'. ik begrijp dat niet helemaal want volgens mij betekent dat gewoon dat ze die certificaten niet zijn tegengekomen, maar als je een eenvoudige aanval ermee kan uitvoeren, dan zijn ze misschien wel gebruikt. Je weet het nooit 100% zeker, en iemand die erdoor genept is zal het niet zo snel melden/door hebben.Comodo claimt dat de ssl-certificaten niet daadwerkelijk zijn gebruikt. De aanvallers hadden de ssl-certificaten echter eenvoudig kunnen gebruiken om man in the middle-aanvallen uit te voeren [...]
Trouwens, ze worden geblokkeerd door Mozilla, Google en Microsoft, maar dat is ook weer niet waterdicht en heeft dus een browser-update nodig. Dat dit soort dingen zo kunnen gebeuren en vervolgens pas na veel moeite weer recht gezet kunnen worden, is zeer vreemd, en misschien moeten we inderdaad maar gaan nadenken over een alternatief/verbeterde versie (al zou ik nu niet weten hoe).
[Reactie gewijzigd door Chris7 op 24 maart 2011 10:16]
Je kan heel goed zien of een certificaat gebruikt is. Bij het controleren hiervan moet het root certificaat van Comodo gecontroleerd worden om te kijken of het uitgevende certificaat (welke aangevallen is) van Comodo correct is. Dus voor elk certificaatgebruik krijgt Comodo een controle verzoek.
Dat hoeft niet. Een CRL check kan uitstaan in de browser, of wellicht geblokkeerd worden door een (Iraanse) overheid. De intermediate CA behoort op de server te staan die het certificaat gebruikt, en de (root) CA zit in de client alszijne trusted authority.
Nonsens. Je download out-of-band een CRL en je browser maakt de beslissing om het certificaat als invalid te bestempelen. Er is geen contact naar de CA die wijst op het gebruik van dat certificaat op een server of (SSL-stripping hardware) proxy.
Comodo heeft ook aangegeven dat ze hebben gekeken in de OCSP logs. Maar ja, als je dat protocol blokt op je nationale firewall, dan heb je het probleem nog steeds.
Comodo heeft ook aangegeven dat ze hebben gekeken in de OCSP logs. Maar ja, als je dat protocol blokt op je nationale firewall, dan heb je het probleem nog steeds.
Flagfox (voor firefox gebruikers) kan ook helpen bij het opsporen van man-in-the-middle aanvallen. Zo kan je het land van de server, die je aan het bekijken bent, zien. Als dit veranderd, gtfo.
Alsof je dat ook niet kan faken (mbv dns poisoning).
Maar het is aannemelijk om de mensen die beweren dat certificaten zwakke plekken hebben gelijk hebben ondanks de bewering van Comodo dat er niets aan de hand is.
Maar het is aannemelijk om de mensen die beweren dat certificaten zwakke plekken hebben gelijk hebben ondanks de bewering van Comodo dat er niets aan de hand is.
in principe niet, een DNS doet niks meer dan redirecten naar een IP, ofwel een IP is altijd terug te traceren naar een land en met de juiste connecties zelfs tot de straat aan toe.
Wat Comodo betreft, gebruik zelf hun anti-virus en die bevalt prima, door dit gedoe zal ik niet eraan denken om daarmee te stoppen o.i.d.
Ieder bedrijf maakt fouten
Wat Comodo betreft, gebruik zelf hun anti-virus en die bevalt prima, door dit gedoe zal ik niet eraan denken om daarmee te stoppen o.i.d.
Ieder bedrijf maakt fouten
Om deze reden is de uitrol en implementatie van DNSSec cruciaal. Deze zorgt er in de 1e plaats al voor dat de DNS cache poisoning niet mogelijk is waardoor je nooit ongemerkt geredirect kunt worden, mits je validatie van de rrsig records doet en bij een invalid of ontbrekend rrsig record de DNS data niet accepteerd.
DNSSec werkt op een soortgelijke manier als de PKI structuur rondom SSL certificaten, waarbij je data door een hogere entiteit gesigned wordt tot boven in de boom. Op het moment dat je een certificaat krijgt wat is gesignd door iets in de boom wat jij vertrouwd (root CA), vertrouw je dus inherent het certificaat. Het grote verschil tussen DNSSec en SSL PKI us echter, __There is only one root__ waardoor de controle veel groter is.
DNSSec werkt op een soortgelijke manier als de PKI structuur rondom SSL certificaten, waarbij je data door een hogere entiteit gesigned wordt tot boven in de boom. Op het moment dat je een certificaat krijgt wat is gesignd door iets in de boom wat jij vertrouwd (root CA), vertrouw je dus inherent het certificaat. Het grote verschil tussen DNSSec en SSL PKI us echter, __There is only one root__ waardoor de controle veel groter is.
Erg leuk, maar het grootste gevaar zit niet bij de DNS poisoning.
Zoek maar eens op wat een land kan doen met een SSL proxy als MITM. Comodo is niet goed wijs om alleen DNS poisoning als probleem op te geven.
Zoek maar eens op wat een land kan doen met een SSL proxy als MITM. Comodo is niet goed wijs om alleen DNS poisoning als probleem op te geven.
Windows had al meteen een update voor me klaar staan toen vanmiddag mijn pc aan ging.
Microsoft is aware of nine fraudulent digital certificates issued by Comodo, a certification authority present in the Trusted Root Certification Authorities Store on all supported versions of Microsoft Windows. Comodo advised Microsoft on March 16, 2011 that nine certificates had been signed on behalf of a third party without sufficiently validating its identity. These certificates may be used to spoof content, perform phishing attacks, or perform man-in-the-middle attacks against all Web browser users including users of Internet Explorer.
Op dit item kan niet meer gereageerd worden.
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
