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 (61)

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

[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

[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]

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

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

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

[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]

[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]

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

[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]

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

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

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

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

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

[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?

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

[heszar]

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.

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

[LOAD81]

Precies de reden waarom ik geen gebruik maak van certificaten.
Bij http heb ik dit geneuzel nooit en dat werkt gewoon prima.