Intermediate TLS-certs 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 uitbrengen 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

Hoewel 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.

Reacties (96)

[frackleboom]

eMudhra heeft inmiddels zelf een verklaring met meer details over het incident gepubliceerd: https://emudhra.com/en/post/certificate-security-incident

[laurxp]

Wat je rustig met een flinke korrel zout mag nemen, trouwens, want dit is voor hun een leven-of-dood scenario. Om een voorbeeld te geven:

Importantly, none of the affected intermediate CAs were deployed in production, with the exception of one. Furthermore, none of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates. This has been confirmed through our internal analysis and corroborated by publicly available Certificate Transparency records on crt.sh.

"Deployed in production" is compleet irrelevant. Dat zegt alleen maar dat zij de sleutels niet gebruikten. Maar omdat het certificaat al aangemaakt en publiek was, waren ze in feite al "live"! Een SSL-certificaat dat ondertekening krijgt van deze "non-production" intermediates zal dan ook gewoon werken.

Ook is het onmogelijk om te weten dat er geen end-entity certs zijn gemaakt. Het enige dat ze weten is dat zij met deze end-entity certs geen intermediates hebben gemaakt. Het is onmogelijk om te weten of potentiële aanvallers dit hebben gedaan, want er is geen enkele harde eis voor een aanvaller om een fraudulent cert in Certificate Transparency op te nemen. Het enige dat we weten is dat er geen fraudulente certs in CT stonden vóór de aanval publiek werd - en de vonst van een cert dat niet in CT staat door bijv. een automatische scantool zou voor alarm hebben gezorgd.
Sterker nog, we weten inmiddels zeker dat er fraudulente certs in omloop zijn - dat is namelijk hoe de check op https://emudhra.we-have-a-problem.com/ werkt!

In de praktijk blijven de risico's gewoon bestaan. Inmiddels zijn de intermediates toegevoegd aan de "zwarte lijst" van Chrome en Firefox, en zal het langzaam maar zeker ook naar alle OSes komen, maar een hoop apparaten en software-pakketten zullen pas véél later een update krijgen - als ze het ooit al krijgen - en blijven voorlopig dus kwetsbaar. Een instant-update "zwarte lijst" zoals Chrome en Firefox is namelijk niet standaard, dat is een DIY dingetje van hun.

[frackleboom]

Het is zelfs nog ernstiger: ook twee code-signingintermediates hadden zwakke sleutels, en code-signingcertificaten worden niet in CT-logs bijgehouden.

[laurxp]

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]

[Standeman]

Doet me denken aan deze scene in spaceballs.

[DvanRaai89]

het equivalent van een gevangenis met een "superveilig 12-cijferig" cijferslot

*115-cijferig cijferslot, en dan enkel waardes van 0..255 kiezen
Want: log₁₀(2³⁸⁴) ≈ 115.595...

[Reactie gewijzigd door DvanRaai89 op 22 oktober 2026 22:31]

[closefuture]

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]

[WargamingPlayer]

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.

[gertvdijk]

Ik denk dat dit meer weg heeft van DigiNotar waarbij de signing en root certificaten gelekt waren.

Ik ben met je eens dat het op DigiNotal lijkt, maar er is een belangrijk onderscheid. In die situatie hadden aanvallers controle over DigiNotars CA-infrastructuur en konden daarmee ongeautoriseerd certificaten laten ondertekenen. Er is geen bewijs dat de private keys van DigiNotars CA's daadwerkelijk zijn verkregen, volgens mij. Ze gebruikten HSMs waar de keys zelf niet uit konden worden gepeuterd.

Wel vergelijkbaar met DigiNotar: betrof ook alleen intermediate (niet root), aantal intermediates affected, ook 8.

[Reactie gewijzigd door gertvdijk op 21 oktober 2026 10:18]

[WargamingPlayer]

Bij DigiNotar hadden ze toegang tot de signing certificaten geloof ik, doordat iemand een netwerk kabel had gelegd tussen de airgapped host omdat het eenvoudiger was om het remote te doen.

[gertvdijk]

Bij DigiNotar hadden ze toegang tot de signing certificaten geloof ik

Bron?

Voor zo ver ik begrijp: bij het DigiNotar-incident waren de CA-servers gecompromitteerd, waardoor de private signing keys in de HSM misbruikt konden worden om frauduleuze certificaten uit te geven.
VZIW is er geen publiek aangetoond bewijs dat de private keys zelf uit de HSM zijn gestolen.
https://zoek.officielebekendmakingen.nl/blg-191225.pdf

Als jij hetzelfde bedoelt, dan zijn we het eens, maar dan heb je mijn punt uit de post waarop je reageert niet begrepen?

In het incident van vandaag bij eMudhra zijn gewoon de private keys op straat. 0 visibility en checks over welke certificaten daarmee worden ondertekend, de signing kan nu gebeuren de een HSM om, gewoon op je eigen laptop nu vandaag kan jij dit doen.
Bij het DigiNotar-incident was toegang tot hun infrastructuur nodig. Je moest dus onderdeel zijn van de boevenbende plat gezegd.

[Reactie gewijzigd door gertvdijk op 21 oktober 2026 12:05]

[WargamingPlayer]

Huib Moderkolk heeft het gereconstrueerd in zijn boek “Het is oorlog maar niemand die het ziet.” maar kan mij de details niet meer herinneren. Enige wat ik daar nog van weet is dat er ingebroken was, dat er een netwerkkabel door een medewerker naar de computer was gelegd, dat de CA gecomprimeerd was.

Maar natuurlijk zijn de echte details nooit boven water gekomen, maar het zal anders gegaan zijn dan de overheid en (ex)werknemers van DigiNotar beschrijven, want die willen natuurlijk niet de onderste steen boven.

[gertvdijk]

Maar natuurlijk zijn de echte details nooit boven water gekomen

Nou ja? Als er daadwerkelijk keys waren gelekt hadden we nog nieuwe certificaten uitgegeven zien worden na het uitzetten van de DigiNotar-infrastructuur.

Er is gewoon geen bewijs voor wat je beweert en juist veel meer aanwijzingen dat de keys daar niet waren gestolen - alleen ingebroken was op de infrastructuur. Weet je eigenlijk wel wat een HSM is?

[WargamingPlayer]

Je bedoeld dat signing kastje dit gebruikt wordt om te ondertekenen. En daar zit wel het verschil in met deze hack. Daar konden ze ondertekenen doordat ze controle daarboven hadden, dus aanhadden de key niet, maar konden wel met de dat signing kastje certificaten tekenen. Effectief heb je dan gewoon de key.

[Reactie gewijzigd door WargamingPlayer op 21 oktober 2026 17:41]

[arjankoole]

Was het in de tijd van DigiNotar niet zodat de root CA direct ondertekende, en intermediates juist daarna pas kwamen, als direct gevolg van de DigiNotar hack en fallout?

[Maurits van Baerle]

Aangezien alle keys lager zijn dan 256 is het best mogelijk dat er een implementatie fout ergens in een interne tool ingeslopen is. Misschien de verkeerde waarde gebruikt.

Bijvoorbeeld wel netjes een PRNG gebruiken om de keys te genereren en vervolgens niet het veld met de keys zelf uitlezen maar het veld ernaast (Volgnummer? Versienummer? User ID?).

Dan treft het dus alleen de gebruikers van die interne tool en niet iedereen in de wereld die een bepaalde library gebruikt.

[Reactie gewijzigd door Maurits van Baerle op 21 oktober 2026 10:06]

[uiltje]

Een interne tool die Internet X.509 certificates / private keys kan gebruiken? Dan is er wel heel veel mis daar. Maar met je eens: dit kan nooit gebeuren als je een goede 3rd party toolset / lib gebruikt.

[laurxp]

Of DigiNotar, waar sleutels bij een hack buit zijn gemaakt en men er pas achter kwam toen iemand in Iran verkeer ging onderscheppen met een vals certificaat voor "*.google.com".

[Llopigat]

Ja maar ik vind dit nog een stapje erger. Diginotar had wel beveiligd maar niet goed genoeg. En het is lastig je te beveiligen tegen een actor met het geld van een hele staat achter zich.

In dit geval hebben ze zelf de private key totaal verprutst, en daar moet je echt moeite voor doen. Ze zijn verplicht deze in hardware te laten genereren maar een hardware generator zal nooit zo'n slechte sleutel genereren.

Dit is duidelijk een of andere test die in produktie terecht is gekomen. Ik denk niet dat het expres is gedaan, als de expres de key hadden laten lekken dan hadden ze gewoon een echte private key kunnen gebruiken. Dat had veel minder opgevallen ook.

[Reactie gewijzigd door Llopigat op 21 oktober 2026 10:28]

[beerten]

De omvang en impact. Niet het veiligheidslek zelf.

[ZinloosGeweldig]

Ik snap de vergelijking met heartbleed niet helemaal. Dat was een bug in OpenSSL die leiden tot een RCE.

Heartbleed lekte data, het was geen RCE vulnerability.

Tenzij je met "leiden tot RCE" de situatie bedoelt waarin er credentials van een user met shell access lekken.

[Reactie gewijzigd door ZinloosGeweldig op 22 oktober 2026 10:04]

[Dannisi]

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.

[laurxp]

8 bits aan entropie, dus. Alles is nul, behalve de laatste byte.

[deadinspace]

8 bits aan entropie, dus. Alles is nul, behalve de laatste byte.

Nee, dat heeft niks met elkaar te maken.

Als een willekeurig gegenereerd getal altijd 5 of 6712389172467716126351 is, dan is dat 1 bit entropie per getal. Namelijk één keuze per getal; het een of ander, A of B, 0 of 1, 5 of 6712389172467716126351.

Het proces van genereren bij eMudhra heeft 8 mogelijke getallen opgeleverd; 8 keuzes is 2³ keuzes, dus 3 bits aan entropie. Dat al die getallen ≤255 zijn betekent niet dat je "een byte aan entropie hebt", dat is niet hoe dat werkt.

[Moes-T]

dat is niet hoe entropie werkt. De lage nummers kunnen perfect gegenereerd zijn door een RNG met 384bit entropy, maar het feit dat er zo veel zijn, is erg eigenaardig en extreem (maar dan echt extreem) onwaarschijnlijk. DAT is waarom de entropie, wat slaat op de RNG en niet de nummers zelf, lager is dan verwacht.

Wat WEL een probleem is met die lage nummers, zelfs als ze van een RNG met 1024bit entropie afkomstig zijn, is dat ze erg makkelijk te brute forcen zijn.

[laurxp]

De huidige consensus lijkt te zijn dat de sleutel is gemaakt door één byte willekeurig te genereren, en de rest expres op nul te zetten. Oftewel: acht bit aan entropie.

[Drumar]

ja, wat is het nou... ;-) een byte is 8 bits... 4 bits heet dan weer een nibble

[uiltje]

Allemachtig, het feit dat dit plus 2 heeft laat wel zien hoe weinig kennis Tweakers bezitten op dit gebied, en laat het gevaar van wijsheid dmv correct klinkende soundbites zien.

[dvz89]

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]

[P1nGu1n]

Het is geen root cert, ook niet "effectief". Een intermediate kan revoked worden, wat ook direct gebeurt is. Bij een root kan dat niet, die moet van de trust list worden gehaald en dan moeten alle system (OS'en, browsers, libraries, etc) geüpdatet worden.

[GertMenkel]

Een rootcertificaat kan ook gerevoked worden. De effectieve eisen van een root en intermediate die in het key store programma van browsers en besturingssystemen meedoen, zijn in dat opzicht niet heel verschillend.

Certificaten van deze autoriteit worden niet alleen meegestuurd met de certificaatketen van de website, ze worden op je apparaat voorgeïnstalleerd. Je moet dus je apparaat aanpassen om dit probleem op te lossen.

Deze certificaten zitten in de besturingssysteemstores van in elk geval Android en Linux (die heb ik gecheckt), en de applicatiestores van Node, Java, de pakketten van Go en Rust, en meer. Die moeten allemaal worden bijgewerkt om met deze intrekking om te gaan.

Voor veel software gaat dat redelijk automatisch, maar op Android staat deze CA ook los in de trust list, dus die moet je handmatig uitschakelen tot de volgende updates komen, net als bij een gecompromitteerde root-autoriteit. Als je geen updates meer krijgt en je telefoon te oud is om die updates van Google te krijgen, moet je dat handmatig doen.

Ook een certificaat van een rootautoriteit kun je prima uit je store gooien. Diginotar is weggehaald (of eerder: expliciet op de niet-vertrouwen-lijst gezet), bijvoorbeeld.

[Paul]

Een certificaat uit je truststore verwijderen is niet hetzelfde als het revoken. Een root cert heeft geen Authority Information Access (AIA) sectie, geen CRL die je kunt downloaden, geen OCSP responder die antwoord. Een root certificaat ongeldig maken is daarom ook erg lastig, je moet het handmatig (of met allerlei tools) uit truststores verwijderen. Een intermediate of een servercertificaat heeft dat wel, en het ongeldig maken van zo'n cert is veel makkelijker: je kunt tegen de uitgever van het certificaat zeggen dat ze het certificaat op de deny-list moeten zetten. Dat is wat revoken is.

Daar zie je ook meteen waarom je een root certificaat niet kunt revoken: een root certificaat heeft geen uitgever; het een een self-signed certificaat.

Gelukkig betreft het hier geen root certificaten, dan waren de poppen helemaal aan het dansen (net als bij Diginotar destijds). Dat gezegd, revoken staat en valt met het daadwerkelijk controleren van de CRL / OCSP. Er zijn genoeg systemen die wel de chain, subject/SAN, en validity controleren, maar niet de CRL.

[GertMenkel]

Maar "emSign ECC Root CA - G3" was een rootcertificaat? Of is dat nog steeds, als je updates mist.

Een CA-certificaat is zelfondertekend, en kan dus naar zijn eigen CRL verwijzen om zich in te laten trekken. Het intrekken van een certificaat is niet veel meer dan een handtekening van het bovenliggende certificaat; bij self-signed certificaten is het certificaat zijn eigen bovenliggende certificaat.

In dit geval is intrekken niet bepaald zaligmakend (iedereen kan zijn eigen CRL maken waar die intrekking niet in zit en de URL naar de CRL MitM'en), maar juist doordat het self-signed is (en het geen certificaat zonder handtekening is), kun je er een CRL in stoppen. In de praktijk gebeurt het zelden maar technisch is het mogelijk. Het kan alleen niet door een derde partij gedaan worden die wel vertrouwd is op dit moment, maar een CA die uit de markt gaat en wiens leafcertificaten allemaal verlopen zijn, kan zichzelf bijvoorbeeld uit voorzorg intrekken.

[Paul]

Maar "emSign ECC Root CA - G3" was een rootcertificaat?

Klopt. Maar dat certificaat is niet één van de acht met een extreem slechte private key. Iedereen, inclusief degene die het gevonden heeft, heeft het steeds over acht intermediate certificaten.

"emSign ECC Root CA - G3" wordt genoemd omdat dat de root is die deze certificaten heeft ondertekend, en omdat een aantal browsers niet alleen de intermediates heeft geblokkeerd, maar dit rootcertificaat óók hebben verwijderd uit hun truststore.

[Paul]

Technisch gezien kun je een random nummer tussen 0 en 2³⁸⁴-1 genereren en een 4 krijgen. Je kunt daar op controleren bij het aanmaken, maar iedere restrictie die je oplegt verkleint de entropie. Dat gezegd, met een entropie-calculatie alles onder de, zeg, 32 bits entropie uitsluiten (dus niet simpelweg alles onder de 4 miljard; dan slaan mensen die brute force proberen gewoon de eerste 4 miljard nummers over en zit je met hetzelfde probleem; 4294967296 is dan een geldige key) is misschien handig om dit soort dingen te voorkomen; op het geheel maken die paar miljard getallen niet zo veel uit, maar knappere koppen dan ik hebben daar vast al over nagedacht.

En keys zijn niet priem nee Bij RSA is de key een afgeleide van twee priemgetallen, bij EC is het een random integer.

[supersnathan94]

Nouja. Ik kan me haast voorstellen dat je bij brute forcen dus keys als “4” overslaat.


Gewoon omdat het niet waar kán zijn.

[uiltje]

Realistisch gezien is dit onmogelijk, de kans erop is simpelweg te klein. Dit is hetzelfde als zeggen dat AES niet veilig is omdat je de sleutel in een keer kan raden. De kans is zo klein dat een controle hierop technisch gezien niet nodig is. Maar je wil wel je systeem zo veel mogelijk beschermen tegen problemen met e.g. de random number generator en additionele controles kunnen daarbij helpen (en ook problemen veroorzaken waar informatie over de sleutel gelekt wordt met side channel attacks, maar goed).

[ZinloosGeweldig]

Bij RSA is de public key het product van twee getallen, waarbij de private key die twee getallen zelf zijn.

Dat het priemgetallen zijn is overigens totaal niet nodig om heel de wiskunde van encryptie en decryptie te laten werken. Dat is alleen belangrijk om de private key private te houden. Want als de twee getallen die je als private key kiest geen grote priemgetallen zijn, is het heel makkelijk om de public key te ontbinden in factoren (en dus een private key te bemachtigen). En om de private key uniek te laten zijn (bij een public key die niet het product is van twee priemgetallen, is elke factorisatie in 2 factoren een geldige private key. Bij priemgetallen is die factorisatie uniek volgens de hoofdstelling van de rekenkunde).

[Reactie gewijzigd door ZinloosGeweldig op 22 oktober 2026 15:18]

[laurxp]

je moet toch ergens een stap hebben om te valideren dat de keys genoeg entropie hebben

Dat zou je denken ja, maar het is dusdanig grote fout dat de meeste mensen in de industrie het zullen hebben gezien als een onrealistisch risico - vergelijkbaar met "wat als aliens binnenvallen" - en er dus geen automatische checks voor hebben.

Dat wil niet zeggen dat niemand die checks heeft. Software van Google heeft bijvoorbeeld een entropie-check bij het genereren van zulke sleutels: bij een willekeurig gegenereerde sleutel (en dat is altijd de bedoeling) zullen er ruwweg even veel 1tjes als 0tjes zijn. Een sleutel die 2/3e 1tjes en 1/3e 0tjes heeft is dus (hoewel niet onmogelijk) nogal verdacht, en je kan die voor de zekerheid afwijzen en alarm slaan. Hetzelfde met een sleutel van "01100001 01100001 01100001 01100001 ...".

Maar goed, dat is dus een Google-dingetje, en nog niet een standaard-ding dat iedereen in de industrie doet. Waarschijnlijk zal daar vrij snel verandering in komen.

Waren die keys niet altijd priem? Of is dat anders bij de elliptic curve cyphers?

Priemgetallen zijn voor RSA. Bij ECC is de sleutel een willekeurig getal, en in principe is ieder getal bruikbaar als sleutel. Dat is ook de reden dat RSA-sleutels zoveel groter zijn: lang niet alle getallen zijn priemgetallen, dus bij RSA kan je alle niet-priemgetallen bij voorbaat al uitsluiten, waardoor de zoekruimte een héél stuk kleiner is.

[Sandor_Clegane]

Je zou haast denken dat het moedwillig is.

[87Dave]

In dit geval is het niet moeilijk om te zien waar ze het vandaan halen.

Een 256 bit key begrepen ze als een key tussen getallen 0-255. Wel ja, misschien eerder als 1-256, goeie kans dat dit kaliber van IT'er niet weet dat het bij zero begint.

Ondertussen gaan er al geruchten rond dat nog meer dergelijke lage private keys van hen gevonden zijn. Zou best zijn als die volledige CA geblacklist wordt totdat ze een volledige niet vriendlelijke audit ondergaan hebben.

[Sandor_Clegane]

Dat geloof je toch zeker zelf niet? Je kan een CA installeren en alles goed inrichten zodat de Chain of Trust uberhaupt functioneert, maar een 256 bit key lees je dan als een getal tussen 0 en 255? That doesn't pass the smell test.

[87Dave]

Het gaat hier over hun private key dat ze zelf kiezen. Die ziet normaal niemand.

Tot nu dat iemand wellicht geprobeerd heeft toch eens wat te brute forcen en direct bij de eerste combinaties al beet had.

[downtime]

Geef dan een reden waarom ze specifiek deze nummers zouden gebruiken als het niet gewoon uit onkunde of gemakszucht was. Misschien zijn het nummers die ze regelmatig over moeten typen (want airgapped PC ofzo) en dat ze daarom voor simpele korte nummers hebben gekozen, omdat ze dachten dat niemand er ooit achter zou komen.

Laten we Diginotar niet vergeten waar de zogenaamd airgapped omgeving gewoon met een kabeltje aan het LAN was gehangen omdat men te lui was om het volgens de regels te doen.

[Sandor_Clegane]

Omdat het meer moeite kost om geen tool te gebruiken om een key te genereren dan om een tool te gebruiken die een key maakt die de systemen slikken.

[svenslootweg]

Een 256 bit key begrepen ze als een key tussen getallen 0-255.

Als dat zo is, wat doen ze dan in godsnaam in deze branche?

[laurxp]

Scheermes van Hanlon:

schrijf nooit iets toe aan kwade opzet als domheid een afdoende verklaring is

[blaatenator]

'nooit' is gewaagd. Tegenwoordig begin ik bij sommige zaken toch echt te vermoeden dat zaken heel bewust gedaan zijn maar waarbij er bij uitlekken richting incompetentie gestuurd wordt.

[Sandor_Clegane]

Hanlon's kop in het zand steken.

[GertMenkel]

Ik betwijfel het, maar ik betwijfel ook dat ze dit niet eerder wisten.

Ze hebben namelijk eerder per ongeluk de correcte sleutels gebruikt om hun CRL te ondertekenen (wat niet matchte en dus de alarmbellen af deed gaan bij Mozilla), toen hebben ze hun setup weer teruggedraaid om de kapotte sleutels te gebruiken. Als dit moedwillig was, hadden ze voorzorgsmaatregelen genomen om te zorgen dat de echte sleutel niet per ongeluk gebruikt kan worden, en hadden ze de boel ook niet in een echte HSM gestopt.

[Gunther.S]

relevant xkcd

[lina inverse]

Echt heel profetisch

[Llopigat]

Wat gek eigenlijk, want ik had begrepen dat private keys altid priemgetallen moeten zijn en de meesten van deze zijn dat absoluut niet.

Edit: Ah wacht. Het gaat om een elliptic curve key, geen RSA. Dat verklaart het. Die gebruiken geen priemgetallen.

[Reactie gewijzigd door Llopigat op 21 oktober 2026 10:26]

[DennusB]

Lekker dagje voor het internet weer dit, sterkte aan alle beheerders!

[kozue]

Een dagje als alle andere. De fix was al geïnstalleerd voordat ik er over las.

[Kip]

Het is veel groter dan dit. Probeer maar een inventarisatie te maken van alle apparaten die iets met TLS doen. Printers, video conferentie apparaten, laadpalen, etc...

[kozue]

Die verbinden naar vaste adressen en staan op een vaste plek. Dan moet je ook al controle hebben over de DNS waar die apparaten gebruik van maken om die om te kunnen leiden. Dat is over het algemeen niet aan de orde voor dat soort vaste apparaten die ergens bij iemand thuis of een kantoor staan. De meeste onveiligheid van dit verhaal zit in mobiele apparaten die niet altijd controle hebben over het netwerk waar ze zich in bevinden.

[cdwave]

Normaal gesproken geef je zo'n apparaat vertrouwen in een en precies een enkele CA, namelijk die van jezelf (je eigen bedrijf). Deze CA wordt ook alleen maar voor dat doel gebruikt.

Een apparaat erop laten vertrouwen dat de komende 30 jaar alle CAs en sub-whatevers ongecompromitteerd zullen blijven is een recipe for failure.

Zo'n apparaat is namelijk geen general-purpose browser die willekeurige sites gaat bezoeken en op een of andere manier moet controleren dat een domein ook echt is wat het claimt te zijn. Het apparaat bezoekt in zijn leven maar een enkele webserver via een vaste DNS naam. Dus hoeft hij ook maar een enkele CA te vertrouwen, en die CA is bij voorkeur niet van een derde partij.

[woutertje]

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).

[WargamingPlayer]

DigiNotar was iets groter, dat waren de root certificaten.

[woutertje]

Praktisch gezien is er weinig verschil tussen de root certificaten en deze certificaten (gesigned door twee root certificaten). Ze kunnen gebruikt worden om certificaten te genereren voor willekeurige domeinen.

Groot verschil is wel dat Diginotar de private keys in handen waren van een hacker, in dit nieuwe geval zijn ze in handen van iedereen die er ook maar enigszins interesse in heeft. Daarom vind ik het persoonlijk groter.

Het is voor veel tooling ook niet mogelijk om intermediate certificaten in te trekken (denk aan curl, maar gaat om bijna alles wat geen browser is), zonder ook het root certificaat in te trekken. Daarom worden er nu halsoverkop nieuwe compiler versies uitgebracht (bijvoorbeeld van Go), of libraries (zoals webpki-roots voor Rust), waarmee iedereen moet recompilen.

[Reactie gewijzigd door woutertje op 21 oktober 2026 10:05]

[WargamingPlayer]

Klopt, ook omdat iedereen met een beetje verstand en AI toegang de Private keys kan genereren. En dus ook werkelijk iedereen.

[deadinspace]

Groot verschil is wel dat Diginotar de private keys in handen waren van een hacker

De DigiNotar private keys waren niet in handen van hackers. Hackers hadden toegang tot de hardware security modules (HSMs) waar de private keys in zaten, dus ze konden naar believen certificaten genereren.

Maar nadat die toegang was afgesloten konden de hackers geen certificaten meer genereren. Bij eMudhra hebben mensen wel toegang tot de private keys en valt er dus geen toegang af te sluiten. Dat maakt het verschil nog groter.

[woutertje]

Je hebt gelijk, dankje. Maakt mijn punt dat dit erger was dan Diginotar nog sterker.

[uiltje]

't is maar net hoe je dat definieert. Root keys horen echt heel goed beschermt te zijn en de certs zijn vaak veel langer geldig. Tevens zijn ze lastiger te revoken. Dit kan goed een probleem zijn bij een andere partij die gecertificeerd was door de CA om zelf ook certificaten uit te geven. Maar klaarblijkelijk gebeurde dat niet in een veilige omgeving want dan hadden deze private exponent (niet key, daar valt ook de modulus onder) waarden nooit gegenereerd.

NB maar volgens mij was vooral het uitgeven van server certs een probleem bij DigiNotar waarbij een intermediate CA dienst was gecompromitteerd. Het is alweer even geleden.

[Reactie gewijzigd door uiltje op 22 oktober 2026 15:16]

[woutertje]

Deze intermediate certificaten kun je zonder ondersteuning van een CRL, wat eigenlijk alleen browsers hebben, uberhaupt niet revoken. Het was ook geen probleem bij een andere partij, maar bij de CA zelf (eMudhra). Het stukje over exponent/modulus gaat in zijn geheel niet op aangezien deze certificaten op Eliptic Curve Crypto (ECC) gebaseerd zijn en niet op RSA.

In dit geval zijn de twee root certificaten van eMudhra waarmee deze intermediates gesigned zijn trouwens uit de meeste trust stores verwijderd.

[cdwave]

Het hele idee dat je certificaten serieus zou kunnen "revoken" is belachelijk als je er een beetje over nadenkt. Dat is op z'n best een leuk extraatje, maar kan nooit structureel enige veiligheid bieden.

[DaaNMageDDoN]

Volgens mij begrijp ik je niet helemaal goed, want zeg je nu eigenlijk: het bestaan van een CRL is belachelijk, een extraa'tje, maar biedt geen veiligheid (?)
De achterliggende gedachte kan ik misschien wel bijkomen: de CAs en wat ze ondertekenen, zou je altijd moeten kunnen vertrouwen, dat is ook het beginprincipe. Maar laten we hier nu een perfect voorbeeld zien waarbij dat niet opgaat. Dan is een CRL m.i. een noodzakelijk iets, want wat anders? CA's uit de store gaan trekken? Geen expiration meer op certificaten, want "we moeten ze altijd kunnen vertrouwen"?
Je zegt CRLs zijn geen structurele oplossing. Volgens mij heb ik iets gemist dan, wat zou dan wel een structurele oplossing zijn (hier)?

[cdwave]

Wat ik bedoel is dat het in de praktijk helemaal niet mogelijk is om eenmaal uitgebrachte certificaten "terug te trekken". Een CRL helpt, maar het is een extraatje, geen op zichzelf staande afdoende maatregel.

Voor een PC nog redelijk te doen, maar voor een embedded device (IoT bijvoorbeeld) betekent het dat het apparaat (1) betrouwbaar moet weten wat de datum/tijd is, (2) de CRL kunnen ophalen en parsen en opslaan in non-volatile storage, (3) regelmatig updates moet krijgen om certificaten bij te werken.

Dat legt allerlei eisen op aan het apparaat: Er moet ineens een RTC op, hij moet een veel uitgebreidere network en TLS stack gaan draaien, hij moet storage hebben, hij moet zich kunnen updaten op een veilige manier. En daar wordt hij niet alleen duurder van, maar ook juist kwetsbaarder, omdat hij bijvoorbeeld niet meer geheel vanuit ROM geheugen kan draaien.

[DaaNMageDDoN]

Bedankt voor je toelichting, zo had ik er nooit over nagedacht. Zijn inderdaad zaken die in praktijk niet werken voor IOT/Embedded. Eerlijk gezegd wel meegekregen waarom mensen IOT devices in een VLAN hangen en/of compleet afschermen van "dingen waar ze toch niet mee hoeven praten", maar dan altijd omdat "je niet weet wat erop draait". Je geeft andere redenen die ook opgaan als je wel zou vertrouwen wat erop draait, sterk punt wat ik eigenlijk nog nooit had gehoord.

[roelboel]

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.

[cdwave]

Wat ik hierboven al postte, een IOT apparaat hoort geen CA lijst te hebben. Een IOT hoort een enkele CA te vertrouwen, namelijk die waar hij mee connect. Hij hoeft niet naar google.com ofzo, hij hoeft alleen maar naar "mycompany.com". Die server zal (naast de gewone publieke certificaten) een certificaat presenteren die alleen voor dit doeleinde gebruikt wordt.

[roelboel]

In theorie klopt het wat je zegt, in de praktijk niet. Om twee redenen. Ten eerste: bij een niet triviaal IoT-apparaat komt er altijd een verzoek ergens uit "de business" om te integreren met een SaaS voor telemetry, crash reports, verzin het maar. Ten tweede: als je in een situatie komt als fabrikant dat al je IoT geen verbinding meer kunnen maken met jouw bedrijf door certificaat-problemen, heb je een probleem. Daarom moet je sterk in je schoenen staan om af te willen wijken van het CA-systeem waar het hele web op draait. Dat gebeurt in mijn ervaring zelden tot nooit. Wat als jouw IoT een enkel CA vertrouwt, zoals Diginotar, Symantec of eMudhra en die game over raken?

[cdwave]

Mijn IOT devices vertrouwen mijn CA certificaat. Niet dat van Diginotar of welke 3rd party CA dan ook. En mijn CA is gewoon self-signed.

Voor het scenario dat mijn CA niet meer goed is, vertrouwen ze ook nog een tweede CA. Ook van mij. Die wordt doorgaans niet gebruikt. Als de eerste CA eruit moet, dan krijgen de devices een firmware upgrade waarin de eerste CA niet meer zit (en eventueel een derde, voor de volgende roll-over).

Wat je uit je hoofd moet zetten is dat een CA iets bijzonders is. Het is gewoon een certificaat, en iedereen kan thuis gewoon een CA maken. Niemand anders dan jijzelf en jouw apparaten zullen het vertrouwen, maar je kunt er wel je eigen chain of trust mee bouwen. En die is juist veiliger dan een "publieke" CA. Hij is alleen niet bruikbaar om je website mee te beveiligen.

En die telemetrie enzo, dat regel je gewoon via je eigen server. Nergens voor nodig dat je devices zelf met Google gaan ouwehoeren.

[Reactie gewijzigd door cdwave op 21 oktober 2026 19:59]

[deadinspace]

Een IOT hoort een enkele CA te vertrouwen, namelijk die waar hij mee connect.

Ik snap wat je bedoelt, maar je bewoording is wel vaag (of gewoon fout) zo. Een IoT device connect niet met een CA.

[WargamingPlayer]

Als je een cert hebt met private key dan is openssl genoeg om een valide certificaat te genereren waarbij je IOT het gewoon slikt.

[roelboel]

Bedoel je te zeggen: “dat is nu mogelijk geworden hierdoor”? Want dat is ook wat ik zeg. Of bedoel je te zeggen “dit kon al”? Want dat is niet correct.

[WargamingPlayer]

Ik stel “in het algemeen” is het hebben van die twee voldoende.

[betwetor]

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.

[thomasv]

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.

[betwetor]

Compleet belachelijk inderdaad. Dat consumenten soms een camera positioneren die niet geheel legaal is, is al fout.

Dat er in de EU volop losse camera's en apparatuur met camera's verkocht worden die de beelden via een non-EU cloud verwerken? Onzin. Bijna zo erg als de omvormers die via het buitenland aangestuurd worden.

Ik zag jaren geleden een project op GitHub die bezig was van die A9 camera's local te kunnen draaien. Waarop ik er een stuk of 50 gekocht heb om in Nestkastjes te monteren. Ik had er alleen geen rekening mee gehouden dat het uiteindelijk niet zou lukken om de firmware te vervangen. Het hoogst haalbare was (platgeslagen) alles laten lopen via je eigen videoserver die de Chinese server moest nadoen via een DNS redirect.

Dat ga ik niet gebruiken op de basisschool.

[Elminster]

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]

[FreezeXJ]

Deze info gaat inderdaad keurig misbruikt worden door teveel mensen, en veel te veel mensen gaan pas door schade en schande leren dat ook IoT-zeut geupdate moet worden.

Je koelkast is straks deel van een botnet, je koffie-apparaat mag dankzij een hack alleen nog maar SuperBonen malen, en je tosti-apparaat bakt ze wel heel erg bruin, als een gekke Chinees dat wil. That will be the life.

Is er eigenlijk al een wet of voorstel om IoT verplicht te laten updaten? Gewoon, minimaal eens per week verbinden met een goedgekeurde server om je laatste privacy-info door te sturen de laatste security-updates toe te passen?

Oh en ga er vanuit dat dit wel is opgemerkt, maar nooit buiten bepaalde kringen is meegedeeld...

[Pinkys Brain]

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.

[kozue]

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.

[4tro]

De beurswaarde lijkt in ieder geval al een opstapje te nemen naar een faillissement

[laurxp]

Het CA-gedeelte in ieder geval wel, ja.

Het probleem is niet zozeer dat ze een veiligheidsincident hebben. Dat kan iedereen overkomen, en er is iedere week wel een incident van het niveau "certificaat is één seconde langer geldig dat toegestaan". De community heeft er best begrip voor dat we allemaal mensen zijn, en met software werken die altijd bugs zal bevatten.

Het probleem is dat ze in dit geval willens en wetens tijdens een veiligheidskritieke "ceremonie" zijn afgeweken van de voorgeschreven procedure, naast de productiesleutel een onveilige testsleutel hebben gegenereerd, en de twee hebben verward omdat de namen op elkaar leken. En toen ze tijdens hetzelfde proces een CRL ondertekenden met de "onjuiste" (veilige) sleutel en bleek dat deze ongeldig was voor de "juiste" (onveilige) sleutel, hebben ze geen diepgaand onderzoek gedaan om te kijken hoe die verwarring is ontstaan, maar hebben ze gewoon #YOLO een nieuwe CRL gemaakt met de andere sleutel.

Dit is een industrie waar alles om vertrouwen draait. Het is de bedoeling dat zulke processen vooraf worden bedacht, op papier worden gezet, worden goedgekeurd door een third-party auditor, en stap-voor-stap worden uitgevoerd door een "maker-checker" paar. Bij een afwijking stop je, en voor iedere fout pluis je tot in de details uit hoe ze hebben kunnen ontstaan en ontwikkel je procedures om herhaling te voorkomen. Er is geen plaats meer voor een Honest Achmed's Used Cars and Certificates, en een partij met de laksheid aan procedures en controles die eMudhra hier laat zien heeft niets te zoeken in het CA ecosysteem.

[FrostyPeet]

Ah, de goede oude tijd. Toen 128 bits private keys nog 64 bitjes hadden aan het begin met de waarde nul Of dat ROT(13) juridisch nog als "encryption" werd beschouwd.

[Stetsed]

Okay, ik zat dit te volgen gister middag toen het allemaal begon, had toen ook geprobeerd de URL op te geven maar zag all dat hij is gedaan. Ik moet heel eerlijk zijn... dit is op zoveel manieren absolute idiotische situatie dat ik geneens weet waar ik moet beginnen.

Als eerste is dit naar mijn mening een van de gevaarlijkste leaks ooit, deze certs zaten in alle grote trust stores die er bestonden. Mozilla, Google, Apple, Microsoft etc, dus elk operating system kan ze vertrouwen. En het probleem en daar moet ik even bot over zijn: We hebben geen universeel mechanism voor revokes, en dit is echt gevaarlijk.

Op browsers hebben we GELUKKIG geen probleem, Chrome gebruikt CRLsets en Firefox OneCRL, dit zijn snelle mechanisms en waren dus all in deze lijsten voor revocation op de 17de voor Chrome/Firefox, Apple heeft een soortgelijk mechanism voor hun hele devices dus die was ook snel. Ik zat er mee rond te spelen toen het net uit was en de browsers die ik gebruikte(Brave, Librewolf) hadden allebei all de updated store.

Echter is het probleem dat dit niet de enige cache is, zoals het artikel all zegt zitten ze op meer plekken. IoT certificaten zouden in theory geen probleem moeten zijn, die moeten eigenlijk helemaal geen volledige certificate store hebben en dat will je ook niet, dat kost te veel storage. Maar er zullen zeker devices zijn die het doen.

Maar elk operating system heeft ook een either certificate store, toen ik er gister bij was zat ik het minute tot minute waren die nog zonder update. Nou heeft Debian wat ik primair draai het gelukkig snel gedaan en die update heb ik nog kunnen doen. Maar iedereen moet ook herinneren voor degene die Docker draaien, docker containers hebben hun eigen certificate store, dus draai daar ook een update voor om die te updaten!

Maar om terug te komen, dit is echt een drama en ik denk dat het niet erger kan. Dit laat ook COMPLETE nalatigheid zien op de kant van eMudhra, dat de nummers zo laag zijn kan technisch een keertje, het zijn valide nummers, maar het is op meerdere certs en zij zeggen het ook all dat dit door hun script komt, ik zie dat sommige mensen zeggen dat het vibe coded was daar kan ik niks over zeggen, maar dit had eigenlijk nooit mogen gebeuren.. absolute drama.