Home   2026-10-22 19:56:51

←

Mozilla vervangt GPG-sleutel voor Firefox en Thunderbird na lek op GitHub

Original article

Mozilla heeft een nieuwe GPG-sleutel aangemaakt voor het ondertekenen van Firefox- en Thunderbird-bestanden. De oude GPG-sleutel was onversleuteld uitgelekt in een privé-GitHub-repository. Mozilla heeft geen bewijs van misbruik van de sleutel gevonden.

Wat is GPG?

GNU Privacy Guard, ook wel GPG, is software waarmee gebruikers berichten en bestanden kunnen versleutelen en digitaal ondertekenen. Dat gebeurt met een sleutelpaar dat een geheime en een publieke sleutel bevat. De leverancier gebruikt de geheime sleutel om bestanden digitaal te ondertekenen. Met de publieke sleutel kunnen gebruikers verifiëren of het bestand daadwerkelijk afkomstig is van de juiste leverancier.

Mozilla gebruikte de GPG-sleutel voor het ondertekenen van Linux-tar-bestanden, rpm-packages en checksumbestanden. Deze belandde per ongeluk in een privé-GitHub-repository. Hoe dat precies kon gebeuren, is niet duidelijk.

Mozilla heeft geen bewijs dat de sleutel is misbruikt. Volgens de Firefox-ontwikkelaar had slechts een kleine groep binnen Mozilla toegang tot de repository. Die groep had via andere kanalen al 'geautoriseerde toegang' tot de sleutel.

Het bedrijf zegt extra beveiligingsmaatregelen te treffen om toekomstige lekken te voorkomen. Het is niet duidelijk om welke maatregelen het gaat.

Gebruikers die GPG-handtekeningen handmatig verifiëren, moeten de nieuwe ondertekeningssleutel en de intrekking van de oude sleutel zelf importeren. Ook bepaalde gebruikers van rpm-packagemanagers moeten actie ondernemen. Dat geldt voor gebruikers van Red Hat Enterprise Linux (RHEL), Rocky en Almalinux, op SUSE en openSUSE gebaseerde distro's en oude versies van Fedora. Zij moeten de sleutel zelf vervangen. Bij gebruikers van Fedora 43 of nieuwere versies doet packagemanager dnf dat automatisch.

Firefox gebruikte de uitgelekte GPG-sleutel onder meer voor het ondertekenen van Firefox- en Thunderbird-bestanden.

Door Imre Himmelbauer

Redacteur

Feedback • 11-08-2026 16:12
18 • submitter: Chocoball

11-08-2026 • 16:12

18

Submitter: Chocoball

Reacties (18)

Tja zo'n belangrijke sleutel hoort gewoon in een HSM te zitten. Dan kan dit niet gebeuren. Raar dat Mozilla dit niet doet.
Hoe kun je zo'n HSM integreren in een CD pipeline? Ik neem aan dat ze automatische builds maken en niet handmatig en dan lijkt mij dat erg onhandig.
Geen idee, ik ben geen ontwikkelaar. Ik heb nog nooit een CD pipeline gezien.

Maar je kan HSM's gewoon automatisch aanroepen door gebruikers of andere sleutels het recht te geven om aanvragen te doen.

De HSM vervangt zegmaar je crypto stack. Dus je maakt een digest van je content, die stuur je naar de HSM en als geauthentificeerde gebruiker maakt de HSM daar dan een signature over. Dus die doet de (asymmetrische) crypto operatie eroverheen. Een HSM is juist bedoeld voor geautomatiseerd gebruik.

Bij ons op het werk gebruiken we ze voor alles. Interne PKI, voor active directory, voor ontwikkelaars enz.

[Reactie gewijzigd door Llopigat op 11 augustus 2026 18:01]

De meeste HSM’s zijn aan te spreken via een API en anders is er altijd wat te bouwen om dit mogelijk te maken. Een CICD-pipeline biedt API-ondersteuning en het zou daardoor dus mogelijk zijn om direct je HSM aan te spreken. Het is overigens geen normale gang van zaken en je kan veel beter enkel het certificaat van een tussenliggende tool ondertekenen.
Natuurlijk doen ze dat waarschijnlijk wel, maar als jij als werknemer even copy-paste doet in je vibecode project, en dat op Github knalt...
Bij een HSM kan je dingen laten signen zonder dat je weet hebt van de private key. Dus dat zou dat probleem hebben voorkomen. Maar een HSM implementeren in je buildstraat daar kleven wel heel wat onpraktische problemen aan. Dus waarschijnlijk is dat de reden dat geen HSM gebruikt wordt. Veiligheid staat vaak tegenover flexibiliteit.

EDIT: Het gaat om een sub-key dus misschien staat de key wel in een HSM.

[Reactie gewijzigd door starquake op 11 augustus 2026 16:29]

Nee zo werkt dat niet. De private key wordt berekend door de HSM zelf en kan die niet verlaten.

Je kan de HSM alleen vragen om dingen te ondertekenen, maar niet de sleutel er uit halen.

Een HSM kan een hele server zijn (op het werk hebben we die van Thales), of zelfs maar een heel klein chipje. Bijvoorbeeld een Yubikey bijvoorbeeld is ook een soort HSM (en ze maken ook een HSM versie).

[Reactie gewijzigd door Llopigat op 11 augustus 2026 16:49]

heel leuk in theorie, maar een failure op de HSM en je hebt geen keys meer, daarvoor moet je redundant zijn en... ohja nu mag je de key plaintext van de een naar de ander overzetten en is hij dus niet exclusief op 1 plek geweest.

majority multisig is nog mogelijk maar daar is de huidige infra absoluut niet op gemaakt.
Dat soort dingen zijn helemaal prima te regelen met een goede HSM hoor (waar Mozilla zeker voldoende geld voor heeft). Ondanks dat ze de sleutel prive houden kunnen ze wel in een cluster samenwerken op een veilige manier. Er is geen single point of failure.

[Reactie gewijzigd door Llopigat op 11 augustus 2026 18:02]

Dat is dus niet waar, je hebt van (onder andere) Thales oplossingen om het key material tussen de (als je het goed doet) drie hsm appliances te verplaatsen. Die keys worden dan versleuteld tussen de appliances over gezet. Dat is best eigenlijk best een mooi proces (key signing). Daarna kan je met een pki omgeving best een systeem maken waarbij niemand ooit zelf wat met zo’n key hoeft te doen..
Is het in jouw hoofd niet een gekke aanname om te doen? Dat het aannemelijk is dat bedrijven die een hardware sleutel gebruiken hier dus altijd kwetsbaar voor zouden zijn?
Phoe. Herinneringen aan jaren terug.

Lang geleden ooit gebruikt om e-mails te ondertekenen en versleutelen. Werd een hele encryptie war over uitgevochten.

Toen werd het snel een niche product. Want tja, iedereen kon een sleutelpaar aanmaken van elk email adres. Er was geen notaris o.i.d. die aangaf dat sleutelpaar X van persoon Y was. Hooguit een e-mail verificatie dat sleutelpaar X bij email adres Y hoorde.

Fijn dat het nog wel in de Linux omgevingen wordt gebruikt voor software verificatie etc.

In principe zou een root sleutel nooit uit de kluis mogen na het ondertekenen van sub-sleutels, de intrek sleutel en het certificeren van de opvolgende root sleutel voor de opvolgende jaren. De sub-sleutels doen het zware werk van het certificeren van gebruikerssleutels.
Ja dat was het oude web of trust van PGP. Omdat er geen centrale autoriteit was zoals een CA, was het de bedoeling dat dat gecrowdsourced werd. Dus jij zou dan de sleutels van je vrienden ondertekenen om ze te bevestigen, en hoe meer ondertekeningen hoe beter zeg maar. Daarom had je ook keysigning parties.

Dit was in mijn oogpunt het slechtste onderdeel van PGP en dat wordt ook niet echt meer gebruikt. De encryptie ansich zit gewoon prima in elkaar. Maar het keymanagement is gewoon een puinhoop.

[Reactie gewijzigd door Llopigat op 11 augustus 2026 17:58]

Web Key Directory Is tegenwoordig populair bij uitwisselen van PGP sleutels voor email. Wordt onder ander ondersteunt door Posteo, Proton Mail, mailbox.org en Mailfence. Er zijn ook wel redelijk wat clients die het ondersteunen zoals Thunderbird (bron)
Is op zich wel te organiseren. Alleen wel kans dat de politie een inval doet als het in bepaalde groepen gebruikt gaat worden. De ironie is dat criminelen de enigen zijn die om versleuteling verlegen lijken te zitten. En die hebben toch geld genoeg om een of ander FLOSS-project te financieren die dit zou kunnen faciliteren. Win-win IMHO
Niet alleen criminelen hoor.. Wordt nog heel veel gebruikt om beveiligingsissues te melden.
Er worden allerlei distros genoemd. Debian en Ubuntu staan er niet bij. Volgens mij gebruikt Ubuntu in de basis ook rpm. Debian apt. Firefox gebruik ik alleen met Ubuntu. Moet ik nu ook iets?
Wanneer je Firefox via Ubuntu gebruikt hoef je niets te doen. Onder Ubuntu wordt Firefox via de snap store gedistribueerd.

Het klopt dat dit enkel van toepassing is voor mensen die de rpm repositories van Mozilla gebruiken voor het binnenhalen van Firefox. Dit zal een relatief kleine groep zijn want de meeste mensen die op rpm gebaseerd distributie gebruiken, zoals Fedora, Alma Linux of OpenSUSE krijgen Firefox via de normale kanalen van hun distributies.

Overigens gebruikt Ubuntu voornamelijk deb packages en geen rpm. Dit komt omdat Ubuntu is gebouwd op de onstable (Sid) branche van Debian.

Om te kunnen reageren moet je ingelogd zijn