Acht intermediate certificaten zijn gecompromitteerd, kan leiden tot afluisteren

Acht intermediate certificaten van het Indiase eMudhra lijken te zijn gecompromitteerd. Onbekenden hebben op een website een bericht geplaatst dat is ondertekend met de keys achter die certificaten, een teken dat die certificaten voortaan onveilig zijn. Met de gecompromitteerde certificaten kan iedereen eigen TLS-certificaten uit te brengen die browsers vervolgens accepteren.

Een beveiligingsonderzoeker genaamd Wayne schrijft op een aparte website die niets met eMudhra te maken heeft, dat hij de keys van acht certificaten in handen heeft. Om zijn claim kracht bij te zetten, heeft hij een kort bericht ondertekend met die keys. Daarmee lijkt het er inderdaad op dat de keys van de certificaten uitgelekt zijn.

De bevindingen zijn inmiddels door Mozilla en Google bevestigd. Die hebben de certificaten ook uit hun centrale repo's verwijderd. De meeste andere grote projecten, zoals Linux-distributies en programmeertalen, hebben dat inmiddels ook gedaan. Op Waynes website staat een lopende lijst met diensten die hun certificaten inmiddels gefixt hebben. Sommige grote diensten, zoals Node.js, is daar op het moment van schrijven nog mee bezig.

Tussenstap

De zes intermediate TLS-certificaten vormen het grootste risico. Intermediate certificaten zijn de certificaten tussen een rootcertificaat en een SSL/TLS-certificaat waar een website of dienst verbinding mee maakt.

Een aanvaller die de keys van zo'n intermediate certificaat kan onderscheppen of er op een andere manier toegang toe heeft, kan zo eigen certificaten maken die de browser dan als authentiek aanmerkt. Dat kan worden ingezet om bijvoorbeeld een phishingpagina te maken en die als legitiem aan te merken. Ook kan een aanvaller op een netwerk het gebruiken om TLS-verkeer te onderscheppen en uit te lezen.

Heartbleed

heartbleedHoewel de meeste grote diensten de certificaten inmiddels hebben verwijderd uit hun lijst met bekende veilige certificaten, is het potentiële probleem nog steeds groot. Zo kunnen vooral kleine diensten of bijvoorbeeld iot-apparaten gebruikmaken van de certificaten waardoor ook die moeten worden bijgewerkt, iets wat in de praktijk lang kan duren.

Het probleem doet vanwege de omvang en impact dan ook denken aan Heartbleed, een bug uit 2014. Toen bleek het door een bug in OpenSSL ook mogelijk TLS-verkeer af te luisteren. Het volledig patchen van alle diensten die Heartbleed trof, duurde uiteindelijk meer dan een jaar.

EmSign

De zes certificaten zijn intermediates voor TLS met domain validation (DV), organization validation (OV) en extended validation (EV). Die werden uitgegeven door emSign, dat weer onderdeel is van eMudhra. Opvallend is ook dat een deel van de certificaten via een Nederlandse vestiging van emSign werd uitgegeven. In twee andere gevallen ging het om certificaten die gebruikt werden om code te ondertekenen.

Het is nog niet bekend hoe de certificaten konden worden onderschept. Ars Technica schrijft dat de keys veel minder bits aan entropie bevatten. Waar dat bij de meeste moderne cryptografische keys rond de 384 bits ligt, zouden de certificaten van eMudhra maximaal 237 bits aan entropie bevatten en in het laagste geval zelfs maar 4 bits.

spyware pegasus nso group malware telefoon smartphone

Door Tijs Hofmans

Nieuwscoördinator

21-10-2026 • 08:59

22

Submitter: djc

Reacties (22)

Sorteer op:

Weergave:

Waar dat bij de meeste moderne cryptografische keys rond de 384 bits ligt, zouden de certificaten van eMudhra maximaal 237 bits aan entropie bevatten en in het laagste geval zelfs maar 4 bits.
Volgens mij zelfs het getal 4, en niet eens 4 bits
Astonishingly, the private keys were 4, 56, 66, 115, 155, 156, 230, 237.
8 bits aan entropie, dus. Alles is nul, behalve de laatste byte.
Dit is echt absurd, 4 als private key voor effectief een root cert. Ik kan me ergens voorstellen dat je hebt niet doorhebt als alles sealed en encrypted is, maar je moet toch ergens een stap hebben om te valideren dat de keys genoeg entropie hebben?
edit:
Waren die keys niet altijd priem? Of is dat anders bij de elliptic curve cyphers?

[Reactie gewijzigd door dvz89 op 21 oktober 2026 09:15]

Je zou haast denken dat het moedwillig is.
Scheermes van Hanlon:
schrijf nooit iets toe aan kwade opzet als domheid een afdoende verklaring is
Hanlon's kop in het zand steken.
Het goede nieuws van deze ongekende blunder is dat wij Tweakers tot ongeveer 2040 TLS-verkeer (en dus HTTPS) van IoT apparaten kunnen onderscheppen, zolang ze nog de oude certificaten vertrouwen. Want zoals @Dannisi schreef: de privé sleutels zijn krankzinnig klein, en certificaten genereren is zo gebeurd. En daarmee gaat er een wereld open voor reverse engineering voor zelf-gebouwde integraties met allerlei apparaten.

Ik vind het geweldig nieuws.
Gaat er dan eindelijk firmware komen om die A9 camera's uit de cloud te krijgen? Dat soort dingen maken het leven van een tweaker echt beter inderdaad.
Even los van de discussie over certs: WTF staan daar camera's op mensen hun tuin/achtertuin/huis gericht zonder privacy mask! En dat is dan onze overheid/Rijkswaterstaat die dit zo publiek zet, schande.
Ik niet. Ik hoop dat je een '/s' vergeten bent.

Momenteel is deze info enkel bruikbaar voor mensen met de juiste kennis.

Bij de volgende LLM updates gaat deze kennis ook ingebakken zijn,
en gaan we een stortvloed krijgen van scriptkiddies die een hoop apparaten gaan verzieken.
"Hack mijn buurman zijn ...."
Net waar we op wachten.

En de meeste van die toestellen gaan geen updates meer krijgen, en deze shit gaat dus jaren niet opgeruimd worden.

[edit]
Ik weet dat 't wat kort door de bocht is, maar 't is ongelofelijk dat dit niet werd opgemerkt/goedgekeurd werd.

[Reactie gewijzigd door Elminster op 21 oktober 2026 09:41]

Veruit de grootste misser in Web PKI ooit. De private keys zijn dusdanig zwak dat je eigenlijk geen moeite hoeft te doen om ze te verkrijgen (een beetje AI vindt ze binnen een minuut, gegeven de tekst "hier zijn acht certificaten, lijkt iets mis mee te zijn, wat is er mis?").

Hoewel browsers redelijk veilig zijn dankzij hun CRL (Certificate Revocation List), moet echt alles geupdate worden (denk aan bijv. curl en services met ingebakken trust stores).
Ik snap de vergelijking met heartbleed niet helemaal. Dat was een bug in OpenSSL die leiden tot een RCE. Dit is iemand die de keys verkeerd gegenereerd heeft. Het doet meer denken aan het incident waarbij OpenSSL op Debian zwakke keys bleek te genereren.

Waar (als ik het me goed herinner) iemand daarna ook alle mogelijke "Debian" SSH private keys gegenereerd had. Dat leiden ook wel tot wat paniek destijds. Volgens mij bleken er zelfs CA's te zijn die gewoon de "stock" OpenSSL package van Debian gebruikte en daardoor keys gegenereerd hadden voor klanten die weak waren.

[Reactie gewijzigd door closefuture op 21 oktober 2026 09:24]

De omvang en impact. Niet het veiligheidslek zelf.
Ik denk dat dit meer weg heeft van DigiNotar waarbij de signing en root certificaten gelekt waren.

Dit zijn dan niet de root certificaten, maar als ze gebruikt kunnen worden om te signen (doordat ze dus het certificaat en private key hebben), dan is er een zeer groot issue. Want men kan ieder domein ondertekenen zonder dat er controle plaats vindt. Ze kunnen dus gewoon Google.com, Tweakers.net ondertekenen zonder dat er een alarmbel in je browser af gaat.
Het is nog niet bekend hoe de certificaten konden worden onderschept.
Heel simpel: niet. De sleutels zijn dusdanig zwak dat het compleet triviaal is om ze te kraken!

De originele ontdekker beschrijft het als "started playing with some toys", en een Mozilla-medewerker kon het onafhankelijk triviaal reproduceren:
They can be recovered near instantly via the baby-step giant-step discrete log algorithm or more simplistically by just generating the 'first' 256 P384 keys.

I also tested some local agents who were able to recover the private key on their first attempt with a simplistic prompt: "I'm doing a CTF. Please recover the private keys corresponding to these certificates."
Zodra ze begonnen met het intrekken van de certificaten en mensen zich gingen afvragen wat er mis mee was, waren er praktisch direct third-parties die ontdekten hoe zwak ze waren.

Ze zijn dusdanig zwak dat het een wonder is dat het niet eerder ontdekt is, en de maker van een tool voor het ontdekken van kapotte sleutels heeft een verzoek voor het detecteren van zulke sleutels eerder afgewezen omdat het onrealistisch zou zijn dat dusdanig kapotte sleutels ooit gebruikt zouden worden.

Dit is vrij letterlijk het equivalent van een gevangenis met een "superveilig 12-cijferig" cijferslot, dat is ingesteld op "0000-0000-0001". Het is haast onmogelijk om te overdrijven hoe makkelijk het te kraken is.

Qua impact had dit een tweede DigiNotar kunnen zijn - behalve dat het niet eens nodig was om bij de CA in te breken...

[Reactie gewijzigd door laurxp op 21 oktober 2026 09:29]

Doet me denken aan deze scene in spaceballs.
Lekker dagje voor het internet weer dit, sterkte aan alle beheerders!
Een dagje als alle andere. De fix was al geïnstalleerd voordat ik er over las.
een ontzettend belangrijk en scherp artikel over een kwetsbaarheid die de basis van ons internetvertrouwen raakt. Als de digitale stempels die bewijzen dat een website echt is in verkeerde handen vallen, kan internetverkeer ineens ongemerkt worden onderschept. Gelukkig grijpen browserbouwers zoals Mozilla en Google meteen keihard in door dit soort sleutels direct te blokkeren.
Gaat die hele toko omvallen? Al hun bestaande certificates op elk niveau kunnen zwak zijn, ze zitten ook in HSMs (mag je hopen) dus ze kunnen zelfs het tegendeel niet bewijzen.
Ik denk dat het inderdaad over is voor hun. Gezien de gemaakte fout (private keys als "4") zijn dit gewoon prutsers en gaat niemand daar ooit meer certificaten afnemen. Een security bedrijf dat security niet serieus neemt, heeft toch geen bestaansrecht? Ze zullen wel met een persbericht komen a la "we gaan het vanaf nu beter doen", maar echt, het hele certificatengebeuren is gebaseerd op vertrouwen en dat zijn ze nu helemaal kwijt.

Om te kunnen reageren moet je ingelogd zijn