Zwakke sleutels bij certificaatverlener eMudhra dwingen Go en Java tot spoedpatches
Het Go-team blikt terug op zijn eerste noodrelease ooit; Java-toepassingen blijven kwetsbaar zolang hun lijst met vertrouwde certificaten niet is bijgewerkt.
De Indiase certificaatautoriteit eMudhra maakte in april 2025 acht tussencertificaten aan met sleutels die door onvoldoende willekeur bijzonder zwak waren. Volgens Help Net Security lag elke privésleutel onder 256, zodat een aanvaller hooguit 256 pogingen nodig had. Onderzoekers haalden de sleutels in minder dan een seconde uit de publieke certificaten, meldt CSO Online. Zes certificaten dienden voor TLS, twee voor het ondertekenen van software. Wie de sleutels had, kon vertrouwde certificaten uitgeven voor eender welk domein en zo websites nabootsen.
Een onderzoeker ontdekte het probleem op 17 oktober. Chrome en Firefox blokkeerden de certificaten nog dezelfde dag, Apple en Microsoft volgden in de dagen erna. Google haalt bovendien het onderliggende rootcertificaat emSign ECC Root CA G3 uit Chrome. eMudhra zegt dat slechts één tussencertificaat in gebruik was en dat er geen klantcertificaten mee zijn uitgegeven. Ongeveer 30.000 certificaten moeten toch verhuizen, en het bedrijf stapt uit de wereldwijde markt voor TLS-certificaten, schrijft Inc42.
In een terugblik van 26 oktober legt het Go-team uit waarom het voor het eerst een spoedprocedure gebruikte. Op Linux controleert Go certificaten met een eigen verifier, zonder ingebouwd intrekkingsmechanisme. Minder dan 7,5 uur na de melding stonden Go 1.27.3 en 1.26.10 online, die de getroffen certificaten weigeren. Het releaseproces zelf duurde bijna 4,25 uur door knelpunten die voordien nooit opvielen. Een volgende keer wil het team zo'n release vooraf aankondigen, en het wil op Linux dezelfde intrekkingsondersteuning als op Windows en macOS. Wie Go-programma's met TLS-verbindingen draait, moet ze opnieuw bouwen met de nieuwste versies.
Ook Java moest bijsturen, meldt InfoQ. Oracle publiceerde een beveiligingswaarschuwing en Azul bracht op 21 oktober buiten de gewone cyclus een update uit die de certificaten in de JDK blokkeert. Azul wijst erop dat Java de intrekking van certificaten standaard niet controleert, zodat een Java-toepassing een vervalst certificaat kan aanvaarden zolang de JDK het niet blokkeert. Een analist raadt bedrijven via CSO Online aan om vooral oudere Java-toepassingen, betaalplatformen, mobiele apps en netwerkapparatuur met een eigen vertrouwenslijst na te kijken.