Chrome en Firefox accepteerden mogelijk nagemaakte certificaten

Een bug in een library die door onder meer Chrome en Firefox wordt gebruikt voor beveiligde verbindingen zorgde ervoor dat nagemaakte certificaten mogelijk werden geaccepteerd. Van beide webbrowsers is inmiddels een update uitgebracht.

Bepaalde waarden in een ssl-certificaat werden niet streng genoeg geparset, waardoor de Network Security Services-library om de tuin zou kunnen worden geleid met valse rsa-certificaten. Dat ontdekten meerdere onderzoekers; een Franse onderzoeker kwam het probleem tegelijkertijd met het beveiligingsteam van Intel op het spoor. Rsa is een van de meestgebruikte encryptie-algoritmes voor certificaten.

Network Security Services is een opensource-bibliotheek voor ssl-verbindingen die onder meer wordt gebruikt in Firefox, Chrome en Chrome OS. Voor beide browsers is vannacht een update uitgebracht. Ook onder meer Thunderbird, de mod_ssl-module van Apache, Pidgin, OpenOffice.org, en Java leunen op Network Security Services. Chrome op Android gebruikt een andere ssl-library.

Het probleem kan alleen worden misbruikt als een aanvaller de verbinding van de bezoeker weet te onderscheppen, bijvoorbeeld door een vervalst wifi-toegangspunt op te zetten, of door een gebruiker naar een vervalste webpagina te leiden. Het is nog niet duidelijk of de kwetsbaarheid ook in de praktijk te misbruiken was. Het Intel-beveiligingsteam belooft een paper vrij te geven met alle technische details van het probleem.

Reacties (28)

[Verwijderd]

Het was vroeger een mooi systeem die certificaten. Maar als ik lees hoeveel problemen er steeds zijn zou ik zeggen dat er wat nieuws moet worden bedacht.

[vide]

Het is een goed en mooi systeem. Cryptografisch is het een heel goed idee en werkt het, maar zoals steeds blijkt het implementeren van zo'n systeem bijzonder moeilijk en foutgevoelig.

Als je een beveiligde verbinding met een website zou willen opbouwen moet je op de een of andere manier:
- de identiteit van de website kunnen bevestigen
- op een veilige manier sleutels uitwisselen
- veilige encryptie afspreken

Uiteraard wordt dit dan op verschillende manieren aangevallen:
Om de identiteit van een website te vervalsen:
- MITM (man in the middle): je proberen te overtuigen een certificaat te aanvaarden dat de identiteit van een website overneemt, of een wildcard certificaat dat goed is voor alle trafiek. Je versleuteld verkeer kan dan via een derde partij gaan die alles kan ontcijferen
- Hash collisions: de bevestiging van identiteit steunt op de ondertekening van het certificaat door CA's (certificate authorities), deze ondertekenen een hash van het certificaat met hun sleutel. Als je een ander certificaat kan maken met dezelfde hash (haalbaar voor MD5, potentieel haalbaar voor SHA1), dan kan je die handtekening overzetten. Vandaar dat o.a. Google SHA2 gaan verplichten.
- inbreken bij een CA om zelf certificaten uit te vaardigen voor bepaalde websites (Diginotar, ...). Mogelijke basis voor een MITM aanval. Kan tegengegaan worden door certificate pinning.

Uitwisselen van sleutels:
- gebruikte entropie is niet altijd voldoende, dus sessie sleutels zouden een te grote mate van voorspelbaarheid kunnen hebben
- als je geen veilige manier van uitwisseling hebt, kan iemand die achteraf de private sleutel van een certificaat te pakken krijgt alle trafiek decoderen. Tegen te gaan door zogenaamde PFS (perfect forward security): een sleutel uitwisselen volgens Diffie-Helman key exchange, daarbij spreek je een sleutel af, zonder dat die over de lijn gaat. Dan moet nog altijd iedere sessie gekraakt worden.
- kwetsbaarheden zoals heartbleed waarbij de private sleutels en sessiesleutels ontvreemd kunnen worden

Afspreken van encryptie:
- vaak gebruiken websites niet de meest veilige codes (AES-CGM is bijvoorbeeld een goed, DES is een slechte, RC4 is ook niet zo sterk). Je zou een beveiligde verbinding kunnen hebben die toch niet zo veilig blijkt te zijn.

Eigenlijk is de conclusie dus dat cryptografisch al die dingen goed en sterk zijn, maar dat de implementaties vaak lekken bevatten (BEAST, Heartbleed, ...) of achterlopen op ontwikkelingen (certificaten nog met MD5-fingerprints, geen PFS, ...)

[[Yellow]]

Als een systeem zoveel verschillende vectoren van aanval heeft, is het dan nog steeds een goed systeem? Ik waag het te betwijfelen.

[vide]

Tja, technisch en cryptografisch goed betekent niet de menselijke factor niet de zwakste schakel is.

Het concept van CA is eigenlijk nog de zwakste link in het verhaal. Het feit dat iedere CA voor ieder domein een certificaat kan afleveren en dat die (vaak) niet de nodige controles uitvoeren om een certificaat af te leveren is een probleem. Vandaar projecten als Convergence (verder voortbouwend op Perspectives). Maar uiteraard kosten die controles van een CA geld (en is ook het geld vragen al een zekere barrière om te voorkomen dat om het even wie om het even welk certificaat aanvraagt).

Verder is ook de eeuwige backwardscompatibiliteit een probleem, als je sneller zou afbouwen, dan zouden bepaalde onveilige constructies al niet meer voorkomen.

Tenslotte vraagt bijvoorbeeld PFS meer rekenkracht dan andere sleuteluitwisselingen wat dan een argument kan zijn om het niet te gebruiken (als je dagelijks een paar miljoen bezoekers hebt, kan dat wel een verschil maken op je loadbalancer en stroomrekening).

[[Yellow]]

Je kunt op 2 manieren je beveiliging regelen: Certificate Authoriies (CA) of Web-of-Trust (WOT).
Certificate Authoriies blijken niet zo heel goed te werken (ik heb het over de praktijk, niet of het theoretisch goed in elkaar steekt).
Web-of-Trust is misschien een beter alternatief. Maar ja, dan moeten vrijwilligers allemaal samen dezelfde software gaan draaien. En dat blijkt alleen te werken als er geld tegenover staat (zie Bitcoin).

Maar misschien is de volgende stap inderdaad wel om (een soort van) Namecoin te gaan gebruiken.

[freaky]

Er zijn echt wel meer manieren hoor. In de toekomst kun je een signature van je certificaat opnemen in je DNS en dan hoef je het helemaal niet te laten ondertekenen door een CA.

En m.b.t. tot je Web-of-Trust, je kunt nu ook al miljoenen likes kopen van een berg Chinezen. Wat belemmert die mensen/bots om WoT te vervuilen met een paar miljoen dit is echt wel veilig meldingen?

Cryptografie is enorm complex. Ook het DNS systeem is niet waterdicht, als ze dat compromiteren is het wel heel makkelijk om niet alleen het certificaat te vervangen, maar gewoon direct al het verkeer naar zichzelf om te leiden bijv.

Er zijn altijd meerdere schakels in dit soort systemen en men gaat eerst voor de zwakste over het algemeen.

Zelfs al weet je al die dingen te voorkomen is er altijd nog de kans dat ze je private key achterhalen, al dan niet met brute force. En ja, bij voldoende key lengte zal dit (mits er geen kwetsbaarheid in het algoritme wordt gevonden) in het algemeen zo lang duren dat het niet interessant is. Je kan ook de eerste poging geluk hebben. Die kans is heel klein, dat is ie bij de staatsloterij ook (wel vele malen groter dan dit overigens ). Er zijn toch echt mensen die met hun eerste de beste lot een keer winnen. Soms heb je gewoon erg veel geluk en in het geval van brute forcen van certificaten heb je al geluk als je hem hebt binnen de eerste 100.000 pogingen oid (is nog steeds heel weinig in verhouding tot 2^2048).

[Nieknikey]

Je reactie slaat kant noch wal. Het concept rondom verificatie van bron d.m.v. certificaten is een goed bedacht concept. Zoals in het artikel vermeld staat worden bepaalde waarden in een ssl-certificaat niet streng genoeg geparset, dit ligt dus aan de implementatie van certificaat verificatie in de Network Security Services-library en doet niets af aan 'het systeem met die certificaten' zoals je zelf zegt.

[Tyrian]

Ik vind zeker dat t-bl een heel belangrijk punt aankaart. Het systeem van certificaten met certificeringsinstanties is alles behalve waterdicht. Allereerst is het aantal vertrouwde basiscertificeringsinstanties (scrabble) ongekend groot geworden. Er hoeft maar één van deze instanties gecompromitteerd te worden en je hebt een gapend gat in het hele systeem. Denk aan DigiNotar bijvoorbeeld. Ook kunnen certificeringsinstanties voor elk domein een geldig certificaat uitgeven. Zo zijn er via gehackte certificeringsinstanties certificaten voor Google uitgegeven terwijl Google daar normaliter helemaal geen zaken mee doet. Maar in de meeste browsers wordt dit gewoon geaccepteerd. En met het aantal certificeringsinstanties die nauwe banden met overheden hebben is het zeer aannemelijk dat bijvoorbeeld de NSA of de GCHQ voor elke server en voor elke website een als geldig geaccepteerd certificaat kunnen laten maken. Daarnaast zijn er de nodige problemen geweest met de gebruikte SSL/TLS cryptografie die niet altijd zo veilig bleek als deze aanvankelijk werd ingeschat, zoals met Heartbleed en de twijfelachtige Dual Elliptic Curve RNG.

[harley]

Ik vind van wel. Mij is altijd geleerd dat iets zo sterk is als de zwakste schakel.
En er komen toch telkens weer zwakke schakels naar boven bij het huidige systeem met certificaten.

Of dat nou ligt aan het certificaat zelf. De uitgevende instantie of de implementatie ergens van het is een zwakke schakel welke de veiligheid in het geding brengt.

[Reactie gewijzigd door harley op 24 juli 2024 18:13]

[henk1994]

Er zit verschil in het systeem en de implementatie van het systeem. Het systeem van certificaten is een goed systeem, maar bij de implementatie worden er wel eens fouten gemaakt.
Een voorbeeld: Als je een sleutel namaakt en je krijg toegang tot een huis, dan is niet meteen het hele systeem van de sloten achterhaald en ouderwets. De implementatie kan echter beter door bijvoorbeeld nieuwe sleutels in te voeren die moeilijker na te maken zijn.

[i-chat]

ik wil nou niet bepaald zeggen dat het een goed systeem is,
een paar bedrijven die miljarden verdienen met het zogenaamd controleren van identiteiten terwijl er toch altijd weer false certs blijken op te duiken,

dnssec is wat dat betreft een klein stapje in de goede rechting maar nu wachten we met zijn allen toch op een uitbereiding naar een systeem waarin je je public key via dns kunt verspreiden zodat http voortaan alleen nog maar over een secure socket mag .. de diensten van bedrijven als comodo etc zijn leuk, en voor een bank, overheid of een dienst als google apps, moelijk zelfs wenselijk, maar voor het merendeel van alle websites zie je nu al dat ssl word gemeden omdat zo'n stom certificaatje te duur is.

[freaky]

Dat valt wel mee hoor. Kan ze inkopen voor ongeveer 6-7 euro per jaar.

Dan heb je wel een DV certificaat, wat alleen het domein valideert - niet het bedrijf/persoon er achter, maar het merendeel van de gebruikers begrijpt het verschil toch niet. Al willen de CA's je graag anders laten geloven... Ik ken echt niet 1 eindgebruiker (geen IT'er dus) die weet hoe het zit.

Bovendien zegt het zelfs dan nog vrij weinig. Als de maker van het certificaat (niet de CA dus die ondertekend het alleen, al dan niet na wat verificaties en het strippen van veel gegevens in het geval van DV's) z'n private key vervolgens overal rond laat slingeren heb je er nog vrij weinig aan.

[DeTeraarist]

Tsja, als we het dan toch over de zwakste schakel gaan hebben, dat is altijd de eindgebruiker en die verknalt het toch altijd. Waarom uberhaupt nog aan veiligheid denken!

[Matthijs8]

Het probleem is alleen dat er een paar honderd CA's zijn die certificaten mogen uitgeven en dat elke CA voor elke website een certificaat kan uitgeven. Als er maar 1 meewerkt met een minder frisse overheidsinstantie of gehacked wordt, kan dat tot grote problemen leiden.
Daarnaast is er ook nog een zeer groot aantal resellers, waarvan er natuurlijk ook 1 of meerderen gecompromitteerd kunnen worden.

[Moartn]

Als er maar 1 meewerkt met een minder frisse overheidsinstantie

Sterker nog: een aantal root CA's ZIJN overheden (zoals de Nederlandse overheid).

[freaky]

Dan zit je bij een reseller binnen. En dan?

Een reseller doet niets anders dan de aanvraag doorschieten naar de CA. De hele validatie procedure loopt daar. De private key waarmee ze ondertekenen zit daar.

CA's zien de private key ook nooit. Nergens goed voor. Ze ondertekenen de publieke sleutel met de private key van het CA certificaat (of meestal met een intermediate eigenlijk) en er staat een LDAP achtig pad in met wat gegevens. In het geval van een DV laten ze daarin alleen de CN in tact en slopen ze de rest er uit (vervangen ze meestal met een melding dat het domain validated is) en bij OV/EV laten ze het meeste er in staan.

Een self-signed certificate is ook niet minder veilig dan 1 ondertekend door een CA qua encryptie perspectief. Je zou dan alleen zelf moeten controleren of het wel het juiste certificaat is. Dat is dan ook eigenlijk het enige dat die CA's doen. Min of meer garanderen dat het certificaat klopt. Een 2048 bit key pair is precies dat, ondertekend door een CA of niet.

[ArmEagle]

Het punt is dat 'het systeem met die certificaten' zwakke schakels heeft. Daarvan zijn de Root CA's de grootste. Er zijn allemaal leuke procedures. Maar een certificaat is door één Root CA ondertekend en daarmee vertrouwen we het maar.

Er zijn uitbreidingen/alternatieven in ontwikkeling waar je niet afhankelijk bent van één Root CA. bijvoorbeeld http://en.wikipedia.org/wiki/Talk:Convergence_%28SSL%29

[Verwijderd]

Het feit dat er bedrijven worden gehackt en dat er nog steeds zwakheden worden gevonden die grote gevolgen kunnen hebben is na mijn mening toch een zorg. Ook al is het concept goed bedacht. Er zijn te veel bedrijven die het uit kunnen geven.

[mraix]

Nieuw systeem gaat niets nieuws opleveren.
Het is maar zelden de techniek die faalt. echte failure is bijv het Diginotar schandaaltje.
( Een CA die niet te vertrouwen blijkt te zijn.... na enige tijd.... )

1. mensen maken fouten.

2. systeem nieuw gaat hetzelfde doen als systeem oud:
je browser, de server en de CA waar de echtheid van zowel jouw browser als van de server worden geauthenticeerd, is de enige manier waarop dit kan werken: 3 partijen die je vertrouwt. Dat is trouwens heel vaak verisign of rapidssl of thawte.
En dat zijn amerikaanse bedrijven die op rechterlijk bevel gewoon de sleutels overhandigen aan hun fbi / nsa enzovoort.

3. bedrijven willen geld verdienen. Ik kon een class 2 certificaat krijgen door een enkel emailtje te sturen vanaf mijn domein, zonder verdere identificatie of verificatie, alhoewel dat met class 2 wel zo hoort. Met andere woorden, dat ssl lockje zegt niet altijd wat for sure.

Het blijft mensenwerk, als t echt veilig moet zijn : pen en papier en zelf afleveren......

[matthewk]

Waar een beveiliging is, zullen anderen proberen deze beveiliging naar beneden te halen. Certificaten zijn daarom niet een slecht systeem. Het is wel zo dat certificaten misschien eens onder de loep genomen moeten worden om het verder uit te werken. Omdat één stukje van een toren niet goed is, ga je toch niet de hele toren slopen?

[mxcreep]

Certificaten, mits goed geimplementeerd, zijn een goed mechanisme. Wat een minder goed mechanisme is zijn de uitgevende instanties, wij moeten er maar domweg op vertrouwen dat zij hun werk goed doen en betrouwbaar zijn. Aangezien de groten zo'n beetje allemaal in Amerikaanse handen zijn ben ik niet snel geneigd ze op hun blauwe ogen te geloven. Voor intranet spul ben ik dan ook een groot voorstander van een eigen CA opzetten en zelf certificaten signen. Intern is het vrij makkelijk d.m.v. policies je eigen certs toe te voegen bij alle gebruikers en je weet zeker dat niet iemand anders met je certificaat kan knoeien.

[appendto]

Het is vooral een complex systeem. De implementatie is ook niet al te makkelijk. Je moet bijna een cryptograaf zijn om het goed te implementeren. Kijk maar eens hoe vaak sites nog een verouderde cipher suite gebruiken.

Vaak is het zo dat een beheerder een certificaat in bijvoorbeeld Apache HTTPD configureert, even testen of het werkt. JA! afblijven het werkt, het is beveiligd. NIET DUS. De volgende vragen worden nooit beantwoord:
- Ondersteun ik TLS 1.1, 1.2?
- Heb ik de juiste cipher suite?
- Staat forward secrecy aan?

Dit alles omdat het te complex is.

[freaky]

Niet alleen omdat het te complex is hoor. Je kan prima je website met alleen TLS 1.2 laten draaien en alleen de meest veilig cipher suites.

Dat heeft dan wel als nadeel dat je tot de conclusie komt dat de clients van een aanzienlijk deel van je bezoekers er niet mee over weg kunnen en dan kan je je af gaan vragen waarom je die site uberhaupt nog draait .

Als iedereen nou eens massaal zou updaten binnen een week was IPv4 al uitgefaseerd, had e-mail geen last meer van spam vanwege een beter protocol, etc.

Bovendien heb je het in mijn woordenboek meer over configureren dan implementeren (ik ken geen mensen die hun eigen SSL stack schrijven) en er zijn redelijk wat tools om je daarmee te helpen.

Zie hier https://sslanalyzer.comodoca.com/ of hier https://www.ssllabs.com/ssltest/ bijv.

De gemiddelde beheerder is tegenwoordig vaak lui echter en als ie niet in 3 klikken door een GUI heen kan en er zelf ook maar 10 minuten voor moet googlen is het al te veel moeite.

[appendto]

Hoezo niet eigen SSL stack schrijven? Ik doe het dagelijks

Wat ik bedoelde met implementeren is: het implementeren van SSL op je site. Verder kun je de cipher suite zo configureren dat het wel met heel veel clients compatible is en dat het toch veilig is. Het is alleen niet makkelijk want laten we eerlijk zijn hoeveel beheerders weten nou wat CBC of ECB is. Ik denk vrij weinig. In mijn beleving is dit veel te complex en foutgevoelig. Hierdoor faalt het systeem volgens mij ook.

[cdwave]

Het grootste lek zit altijd tussen het scherm en de stoel.

Daarbij komt nog dat het de gebruiker makkelijk wordt gemaakt om serieuze problemen te negeren. Zo heb ik nooit begrepen waarom alle browsers een ongeldig certificaat toch laten accepteren met een enkele muisklik. Waanzin.

[mutley69]

Het kan altijd - alles werkt op basis van vertrouwen - en waarom is DNSSEC nog altijd geen wettelijke verplichting??? Want zo lang dns niet gesigned is - kan het internet NOOIT veilig worden.

[Thundy]

Wat jij zegt kan al niet meer sinds de introductie van de HSTS header en heeft verder niks met bugs te maken.