Google ontdekt valse ssl-certificaten voor Google-sites

Een Indiase certificaat-autoriteit heeft valse ssl-certificaten voor verschillende Google-domeinen uitgegeven. Daardoor waren vooral gebruikers van Internet Explorer kwetsbaar. Het is onduidelijk hoe de certificaten zijn vervalst.

Google kwam de valse ssl-certificaten 2 juli op het spoor, zo heeft het bedrijf bekendgemaakt; het National Informatics Centre in India, een onderdeel van de Indiase overheid, gaf de certificaten uit. Inmiddels zijn de certificaten van die autoriteit ingetrokken.

Alleen Microsoft accepteerde de certificaten van de Indiase organisatie. Naast Internet Explorer gebruikt Google Chrome de certificaat-database van Microsoft, maar omdat Google een lokale kopie van zijn server-certificaten op de pc's van gebruikers opslaat, zou Chrome de vervalste certificaten voor Google-servers niet hebben geaccepteerd. Als de certificaat-autoriteit echter ook valse certificaten voor andere domeinen heeft uitgegeven, zouden ook Chrome-gebruikers kwetsbaar zijn. Of dat is gebeurd, is onbekend. Hoe de certificaten vervalst zijn, is onbekend.

Eveneens is nog onduidelijk hoe de valse certificaten zijn uitgegeven. Elke certificaat-autoriteit kan voor elk domein een ssl-certificaat uitgeven, waardoor één autoriteit die valse certificaten uitgeeft de veiligheid van het gehele internet in gevaar brengt. In 2011 ging een Nederlandse certificaat-autoriteit, DigiNotar, failliet nadat het bedrijf meer dan anderhalve maand stilhield dat het was gehackt en er certificaten waren buitgemaakt.

Reacties (44)

[Verwijderd]

Het zal ongetwijfeld aan mij liggen, maar ik snap het volgende niet:

Alleen Microsoft accepteerde de certificaten van de Indiase organisatie. Naast Internet Explorer gebruikt Google Chrome de certificaat-database van Microsoft, maar omdat Google een lokale kopie van zijn server-certificaten op de pc's van gebruikers opslaat, zou Chrome de vervalste certificaten voor Google-servers niet hebben geaccepteerd.

Ik snap dat Chrome ze niet accepteerde vanwege de locale kopie van server certificaten, maar wat heeft dat te maken met dat Google Chrome de certificaat database van IE gebruikt?
En hoezo zijn andere browsers dan niet kwetsbaar geweest, zoals FireFox?

[Niemand_Anders]

Chrome heeft waarschijnlijk voor de fingerprint van het Google 'root' certificaat in de code staan, het kan ook zijn dat Chrome een lijst van de belangrijkste certificaten heeft, maar het concept veranderd daardoor niet. DigiNotor had in het verleden inderdaad al eens onjuiste Google certificaten uitgegeven en daardoor kon Iran daarmee beveiligde berichtgeving onderscheppen.

Dus ik vermoed dat Google daarom hardcoded de fingerprint van hun certificaten hebben opgenomen. Dat heeft als nadeel dat als dat 'root' certificaat verloopt je een update van de software nodig hebt. Nu wordt Chrome al automatisch en regelmatig geupdatet dus dat is meer een detail. Het voordeel is dat Chrome dus niet vatbaar is voor valse certificaten omdat het deze gewoon negeert. Chrome zal de key-chain controleren en in die chain moet dat (root) cerificaat waarvan de fingerprint in de code staat zijn opgenomen.

Daardoor zijn de Google servers niet vatbaar, maar als de Indiase CA ook 'valse' certificaten heeft uitgegeven voor laten we zeggen Cloudflare dan zal Chrome dat niet detecteren.

Firefox houd zijn eigen CA key store bij. Aangezien deze Indiase CA ook overheids certificaten uitgeeft en Firefox deze CA niet in de lijst heeft staan, betekend dat in principe dat je dus geen Indiase overheids websites kunt bezoeken zonder dat je een melding krijg dat het certificaat ondertekend is door een onbekende partij. In de meeste gevallen betreft het dan een self-signed certificaat.

Chrome maakt gebruik van de Microsoft key store. Dat heeft als voordeel dat als jij het CA certificaat van je eigen bedrijf daarin plaatst, bezoekers op het intranet geen meldingen krijgen bij MSIE en Chrome. Firefox gebruikers zullen expliciet zelf dat certificaat moeten toevoegen. Dat is zo'n klein puntje waaruit blijkt dat Firefox niet echt geschikt is voor de zakelijke gebruiker. Na stond er al eerder deze week een bericht op Tweakers dat het marktaandeel van Firefox gezakt was, maar ik vermoed dat Firefox in India een zeer klein markt aandeel heeft.

De meeste gebruikers zitten niet op een 'Ikea' browser te wachten welke na het installeren nog niet geschikt is voor hun land. Als je na de installatie zelf nog allerlei root certificaten moet installeren zullen veel potentiele gebruikers afhaken. Windows wordt overal ter wereld gebruikt en daarom heeft Microsoft een van de meest uitgebreide standaard key stores. Google maakt daar handig gebruik van.. Firefox doet dat niet. Dat is een keuze welke voor- en nadelen heeft.

[Equator]

Chrome heeft inderdaad de fingerprints van de certificaten van Google.* ingebakken. Je kan het controleren en aanpassen hier: chrome://net-internals/#hsts

Let op, is wel een expert feature, want je maakt het zo ook erg snel stuk

[michelr]

"Firefox is not affected because it uses its own root store that doesn't include these certificates."

[Sebazzz]

Chrome gebruikt de store van Microsoft / Windows én heeft speciale 'overrides' voor Google erin zitten. Firefox heeft zijn eigen store, mogelijk Opera ook.

Ik denk overigens dat dit gewoon een smerig spelletje van India is. Met die vervalste certificaten kan je heel gemakkelijk een man-in-the-middle aanval uitvoeren en verkeer naar Google afluisteren en zelf manipuleren. Het zou helemaal niet gek zijn dat India zoiets zou willen. Ze hebben zich wel vaker negatief opgezet tegen de vrijheid van het internet.

[BeosBeing]

Er is één oplossing: geen enkele CA meer vertrouwen. Of ze nu gehackt zijn zoals Diginotar, omgekocht, geïnfiltreerd of misleid, in principe kan dit bij iedere CA gebeuren. Een certificaat dat door één identiteit is gevalideerd, ongecht of dit een CA is, een anderssoortige authoriteit (overheid), een anderssoortige organisatie (bedrijf, stichting, ngo) of een persoon, ze zij allemaal vatbaar voor hacken, omkoping, infiltratie, misleiding of intimidatie en dus niet te vertrouwen. Een certificaat kan alleen betrouwbaar zijn als het onafhankelijk door meerdere (absolute minimum is 3) personen of instanties is goedgekeurd, bij voorkeur door instanties die je persoonlijk kent.

[WhiteDog]

Ik denk dat ze bedoelen dat Google Chrome op Windows ook de certificaten-database van je Windows installatie gebruikt. Java doet dit ook.

[Verwijderd]

klopt.
Alleen voor hun eigen domeinen hebben ze in chrome zelf een kopie van de server certificaten.
Daarom zijn chrome users niet kwetsbaar op Google domeinen maar mogelijk wel op andere domeinen

[Verwijderd]

klopt.
Alleen voor hun eigen domeinen hebben ze in chrome zelf een kopie van de server certificaten.
Daarom zijn chrome users niet kwetsbaar op Google domeinen maar mogelijk wel op andere domeinen

Dat betekend dat chromium en chrome voor Linux en waarschijnlijk Android en OSX in geen enkel geval kwetsbaar waren want er bestaat geen Microsoft certificaten store voor deze OSen.

Dit had Tweakers ook mogen uitsplitsen. Er wordt niet alleen maar Windows gebruikt.

[vide]

Chromium gebruikt NSS store en bij OS X is het de certificate store van het systeem, zie: http://www.chromium.org/Home/chromium-security/root-ca-policy

[Armin]

En hoezo zijn andere browsers dan niet kwetsbaar geweest, zoals FireFox?

Enkel Microsoft had de certificaat uitgever als trusted. Dus enkel software (zoals IE én ook Chrome) die de Microsoft trust store gebruiken zouden het certifciaat accepteren. Firefox gebruikt haar eigen store (die minder volledig is en ze in dit geval dus 'redde'.).

Zou je op iOS of Android dus een volledig legitieme site bezoeken van die zelfde uitgever, zou je een eng rood schildje krijgen. Dus die andere platformen waren niet kwetsbaar omdat ze de hele uitgever niet ondersteunden.

Dan Chrome. Die gebruikers hebben geluk dat het een vals Google certificaat gebruikt, en Google voor haar eigen certificaten een soort whitelist heeft die aangeeft of het wel een correct certificaat is.

Dat ze ook een eigen additionele store hebben is waar, maar niet relevant in deze. Had een een vals Facebook, twitter of Tweakers.net certificaat betroffen, zou ook Chrome kwetsbaar zijn. En wie weet, wellicht was het valse Google certificaat niet het enige. Het feit dat het hele intermediate certifciaat ingetrokken is, doet vermoeden dat ze het niet kunnen uitsluiten ...

De werkelijke vraag is dan ook hoe is dit gekomen?
- Is het intermediate CA gejat of echt gebruikt?
- In dat laatste geval, aan wie, want dan is er een paper trail.
- Is het een bewuste actie geweest van de CA of procedure fout?

Een jaar of wat geleden is exact hetzelfde gebeurd in Frankrijk, waar het ministerie van defensie een vals Google certifciaat aanvroeg bij de Franse overheid. Die gaf het zodat defensie kon spioneren bij Google gebruikers. Aldus de Franse CA een procedure fout ('zogenaamd' geen controle of Google.com wel eigendom was van de aanvrager - de Franse defensie), maar velen vermoeden anders ...

Hier dus diezelfde vragen.

[Equator]

Het gaat hier dus niet over het 'vervalsen' van certificaten. Er is door een CA een (of meerdere) certificaten uitgegeven op een domein van Google welke niet aangevraagd zijn door Google zelf. Dat zo een aanvraag er door heen komt heeft meer te maken met de kwaliteit van de aanvraagcontrole. En die is blijkbaar niet zo goed of kan worden aangetast met een zak geld. (bijvoorbeeld)

Dat is eerder gebeurd bij een CA die certificaten heeft uitgegeven voor Microsoft.com.

Het is overigens niet alleen Internet Explorer die kwetsbaar is, maar in wezen alle programma's die gebruik maken van de Microsoft internal Trusted CA Store.

[Reactie gewijzigd door Equator op 24 juli 2024 00:37]

[SunnieNL]

kwetsbaarheid is het ook niet direct. Het is een gevolg van het hele systeem.
Microsoft vertrouwd de CA (wat ook normaal is als je door een bepaalde procedure heen komt) en daarop worden automatisch alle uitgegeven certificaten vertrouwd.

Weet iemand of Mozilla dezelfde CA ook vertrouwde?

[dtech]

Nee, alleen Microsoft had deze CA root in haar stores. Firefox gebruikt Mozilla's store waar deze niet in zat.

[Equator]

Je bent kwetsbaar op het moment dat er iemand misbruik kan maken.

In dit geval is de kwetsbaarheid dat men een MITM aanval uit kan voeren door jou als internetter een veilig gevoel te geven (je hebt immers een veilige verbinding met Google) terwijl je potentieel een verbinding hebt met een server van de overheid die doet alsof ze Google zijn.

Of dit het geval is geweest valt natuurlijk niet zo snel te achterhalen.

[androgeus]

Dat zijn dan dus valse certificaten.

[Equator]

Maar 'vervalsen' betekend namaken, een onechte kopie ergens van maken. Ik begrijp de zinsnede wel, maar vind het niet geheel correct.

[drdelta]

Het zou inderdaad eerder 'oneigenlijk uitgegeven certificaten' moeten zijn.

[Verwijderd]

Je kunt ook de definitie van "vervalsen" verbreden tot "iemand laten geloven dat iets iets is, terwijl dat niet zo is", oid.

[ILUsion]

Maar een CA bevindt zich nu eenmaal in de positie om dergelijke certificaten uit te schrijven. Wat er hier gebeurd is, is in mijn ogen ook niet vervalsen, maar valselijk uitgeven. Een beetje alsof de nationale bank biljetten zou gaan bijdrukken (dat mogen ze in principe ook en ze moeten die biljetten dus niet vervalsen), maar dat ze daartoe de opdracht gekregen hebben van iemand die daar helemaal niet over mag beslissen. Maar je zou zo'n biljetten amper "vals" kunnen noemen: ze zijn dan identiek aan de "echte".

Hier heeft die CA ook alles in huis om echte certificaten af te leveren, en technisch gezien is er niets verschillend aan die valse certificaten (i.e. valselijk uitgegeven) en echte certificaten, alleen de manier waarop ze tot stand zijn gekomen is anders.

Maar dit laat eigenlijk opnieuw zien dat CAs nog veel betrouwbaarder gemaakt moeten worden.

[GravGunner]

Ik vraag me af waarom er nog geen constructie bestaat waarbij (grotere) aanvragers een code dienen af te geven om zo de aanvraag te bevestigen.
Ja het is een extra stap, maar je wint er wel veiligheid en betrouwbaarheid mee.

En dan bedoel ik een code zoals die uit een token komt rollen. Snap dat het lastig kan worden met de verschillende CA's, maar ook daar is vast een oplossing voor te vinden.

[robvanwijk]

Zo'n systeem bestaat al: Extended Validation. Het punt is alleen, ik ben niet op de hoogte van een methode om aan browsers door te geven dat ze alleen een EV certificaat mogen accepteren voor een bepaald domein (bovendien, ook EV certificaten zijn uiteindelijk niet waterdicht en kunnen eventueel ook vervalst worden natuurlijk).

[drdelta]

Het blijft een Google certificaat. Die zou alleen eigenlijk niet door die instantie uitgegeven mogen worden. Als de gemeente (per ongeluk) informatie aan een burger geeft die hij niet mag hebben, is die informatie daardoor nog niet vals.

[Wh4ck0]

Nee, maar als jij naar de gemeente gaat en een paspoort aanvraagt onder de naam Jan Met de korte achternaam, dan heb je wel degelijk een vals paspoort

[drdelta]

Ja, omdat het paspoort uitgegeven wordt voor een persoon die ik niet ben. Het certificaat is/was echter gewoon voor google.com (bv) uitgegeven, hij is alleen aan de verkeerde instanties afgeleverd. Als ik een paspoort aanvraag, en die krijg jij in handen, dan is dat paspoort nog niet vals.

[mad_max234]

Valse betekend ook onbetrouwbaar, valse is dus prima in deze context te gebruiken.

Groep valse mensen zijn ook geen namaak mensen, maar gewoon echte mensen maar zijn onbetrouwbaar. Valse ssl sleutels zijn dus onbetrouwbare sleutels, of ze namaak zijn of niet is geen absolute definities om valse te zijn.

[Verwijderd]

Valse betekend ook onbetrouwbaar, valse is dus prima in deze context te gebruiken.

Groep valse mensen zijn ook geen namaak mensen, maar gewoon echte mensen maar zijn onbetrouwbaar. Valse ssl sleutels zijn dus onbetrouwbare sleutels, of ze namaak zijn of niet is geen absolute definities om valse te zijn.

Als je het hebt over valse mensen dan wordt er met vals boosaardig, oneerlijk of gemeen bedoeld. Dus je vergelijking gaat mank.
Het gaat hier om producten en daarbij is de betekenis van vals nagemaakt of afwijkend van het origineel. In de zaak die in het artikel besproken wordt gaat het ook daar niet om. Oneigenlijk uitgeven zoal drdelta schreef is dan ook beter in dit geval.

[begintmeta]

Er zijn wel meer dergelijke gevallen bekend (Türktrust bijvoorbeeld), voor veel mensen zijn een hoop standaard-CA's van diverse browsers en besturingssystemen ook niet direct noodzakelijk, voor velen zou het daarom geen slecht idee zijn om nog wat weg te snijden uit die standaardlijsten, en/of altijd goed te kijken naar welke CA het certificaat heeft uitgegeven.
Eerder werd eens aangegeven dat dit het systeem zou ondermijnen, omdat men vanwege frequente meldingen niet meer zou kijken naar de waarschuwingen. Maar IMHO wordt het systeeem eerder ondermijnd door het overbodig activeren van CA-goedkeuringen, en het uit luiheid niet zelf controleren van CA's en certificaten)

[Reactie gewijzigd door begintmeta op 24 juli 2024 00:37]

[Nees]

En hoe maken ze eigenlijk een geldig certificaat? Gaat iedereen ervan uit dat het certificaat dat ze gekregen hebben, geen vals is? Kan dat niet gechecked worden?

[Cartman!]

Dat is juist waarvoor je CA's hebt, als zij er een voor je maken hoor je erop te kunnen vertrouwen dat ze echt zijn. Probleem is dat er veel CA's zijn en de zwakste schakel het probleem vormt.

[Equator]

Zoals door Cartman al gemeld: Het gaat daarbij volledig om het vertrouwen van een CA. Gelukkig zijn er regels waar een CA zich aan zou moeten houden. Helaas worden deze regels om onbekende motivaties wel eens overtreden. Zolang dat niet bekend wordt is er niets aan de hand, zodra het bekend wordt ga je nat. Vertrouwd niemand je CA meer en ga je geheid failliet.

Natuurlijk zijn er ook situaties waarbij de CA volledig juist handelt, maar is er een lek in de aanvraag/controle procedure, of heeft iemand ongeautoriseerde toegang tot het systeem verkregen. De CA is kwestie moet dan adequaat reageren, en niet zoals DigiNotar de boel stil houden.

Meestal (en dat is in dit geval ook zo) is het niet de Root CA die de problemen geeft, maar juist een intermediate CA (een onderliggende CA).

[Reactie gewijzigd door Equator op 24 juli 2024 00:37]

[Soldaatje]

Ik neem aan dat deze CA meteen op de blacklist komt?
Het risico is gewoon te groot om ze te blijven vertrouwen.
Ook een goed signaal aan andere CA's: get your shit together or bye bye.

[Verwijderd]

Er zijn alternatieven voor de huidige CA structuur. Mede ontwikkelt door Moxie Marlinspike die ook een zeer interessante presentatie heeft gegeven over de toekomst van SSL en CA's.

Hier de presentatie : https://www.youtube.com/watch?v=Z7Wl2FW2TcA
Hier het alternatief voor de CA's : http://convergence.io/

[Blokker_1999]

Uiteindelijk doe je daar gewoon hetzelfde. Men noemt het alleen geen CA maar een notary. Vandaag kan jij ook bepalen welke CAs je wel of niet vertrouwd, alleen doet niemand dat en gaat men er van uit dat softwaremakers weten waarmee ze bezig zijn. Je moet nog altijd vertrouwen op iemand anders en de reputatie ervan. Net zoals vandaag met de CAs

[dtech]

Web-of-trusts zijn in de praktijk erg complex en helemaal niet zo betrouwbaar. Er hoeft maar 1 prominente schakel te zijn met kwade bedoelingen om het hele systeem onderuit te halen (totdat het ontdekt wordt).

Stel je voor dat WoT gemeengoed wordt. De gemiddelde gebruiker trapt al bijv. in van die links waarmee ze facebook onderspammen. Hoe moeilijk is het denk je om een malifiede node in hun netwerk te krijgen?

Dus op dit moment zijn er nog geen goede alternatieven.

[Pinkys Brain]

Doe mijn maar gewoon DANE, jammer alleen dat klaarblijkelijk alle grote browser devs de certificaten industrie niet tegen zichzelf in willen nemen en DANE weigeren te ondersteunen.

[regmaster]

Sowieso moet je stoppen met het vertrouwen van CA's want het gehele 'web of trust' idee is al enige tijd een zeepbel gebleken welke nu steeds vaker uit elkaar klapt.
Hoeveel valse certificaten zijn er in omloop wat we niet weten en worden standaard als valide door webbrowsers geaccepteerd? Maar goed, het lastige is dat er niet zo heel veel alternatieven zijn om de beveiliging van websites te regelen. We moeten noodgedwogen gebruik maken van een beveiligingssysteem waarbij te hopen valt dat er niet al teveel schurken misbruik van maakt. Niet een lekker uitgangspunt maar het is wel de realiteit.

[vide]

Het is ook mogelijk om in Internet Explorer certificate pinning te doen, maar dan moet je wel EMET installeren en de nodige regels zelf configureren. Niet iets voor de gewone gebruiker dus Maar dat zal het nooit worden natuurlijk: stel dat je zoiets doet en het certificaat vervalt of wordt legitiem vroegtijdig vervangen, dan ga je waarschuwingen of foutmeldingen krijgen en we weten allemaal dat de meeste gewone gebruikers dan in paniek geraken.

Er is echter geen reden dat Apps (die quasi per definitie regelmatig worden bijgewerkt) op smartphones dat niet zouden doen voor de diensten die ze gebruiken. Iemand zin om dat te testen voor internetbankier-apps. Makkelijk te doen: je verkeer langs een proxy laten lopen die SSL-verkeer ook verwerkt (nadat je het *.* certificaat daarvan hebt geïnstalleerd). Krijg je waarschuwing/foutmelding: goed, werkt het gewoon, dan ben je kwetsbaar.

[batjes]

Microsoft wou EMET onderdeel maken van Windows 8(of teminste dat was gerumored) maar heeft dat niet gedaan ivm backwards compatibility (het breekt heel makkelijk oude XP era software).

Ik hoop zelf dat EMET onderdeel van Windows 9 word. Fuck die backwards compatibility nou een keer, ik raad iedereen aan EMET te gebruiken, je kunt apps toch whitelisten dat EMET ze met rust laat.

[Virtlink]

Elke certificaat-autoriteit kan voor elk domein een ssl-certificaat uitgeven, waardoor één autoriteit die valse certificaten uitgeeft de veiligheid van het gehele internet in gevaar brengt.

Wat een idioot systeem. Waarom heeft elke domeinhouder niet een eigen privésleutel die nodig is om een certificaat te kunnen maken? Op die manier kan alleen de gekozen certificaat-autoriteit certificaten maken, en de andere autoriteiten niet.

En iedereen (bijvoorbeeld certificaatdatabasehouders zoals Microsoft) zou kunnen verifiëren dat het certificaat legaal gemaakt is met de publieke sleutel van de domeinhouder.

[Eloy]

Ik kan dan nog steeds een privé steutel maken, en zeggen tegen een CA: "Ik ben Google.com en dit is mijn zelfgemaakte privé sleutel voor Google.com"

Het is aan de CA om te controleren of dit klopt. In het geval van Diginotar is het dus niet gecontroleerd omdat ze gehackt waren.

[mutley69]

Diginotar root-certificaten zitten in nog veel browsers...

[dentitten]

Ik denk dat ik dit gisteren zou kunnen gemerkt hebben. Mijn vriendin riep me ivm computerproblemen. Ik ga naar boven en zie Internet Explorer. Dus laten we beginnen met Chrome te downloaden. Chrome raakt niet op google.be omdat 'deze pagina lijkt niet de echte te zijn...'. Nu vond ik niet meteen een oplossing en ik ben niet blijven zoeken want ik had al 5 doelpunten van de Duitsers gemist !
Na dit te lezen zou ik vermoeden dat je in je internet opties de gekende certificaten kan verwijderen ? (Ik ga er van uit dat vriendin een verkeerd certificaat heeft aanvaard) Om dan wanneer ik opnieuw naar google surf het correcte te aanvaarden ? Of optie 2: dit heeft allemaal niets met elkaar te maken.

[Reactie gewijzigd door dentitten op 24 juli 2024 00:37]