Anderhalve week geleden bleek het intermediate code-signing certificaat van Mozilla, op dat moment opgenomen in alle browser extensies, genaamd signingca1.addons.mozilla.org met serienummer "10:00:04" te zijn verlopen - waardoor alle extensies als onveilig werden aangemerkt en daarom uitgeschakeld. Dat is duidelijk geen 64 bit serienummer (het is maar 3 bytes lang zoals te zien is in een ASN.1 editor). Maar misschien was het op 4 mei 2017 (de uitgiftedatum) nog niet helemaal doorgedrongen dat 64 bit randmoness een vereiste was/is.

Echter, als het random zijn van dat serienummer zo belangrijk is, waarom heeft Mozilla dan anderhalve week geleden een update van dat certificaat met aangepast verloopdatum, met een eveneens 3-bytes lang serienummer "10:00:08", toegevoegd aan de certificate store van alle Firefox gebruikers?

Uit https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/:

Als Mozilla zich daar zelf niet aan hoeft te houden, waarom moeten gebruikers van PKI Overheid certificaten dat dan wel? Complete onzin dit.

Het lijkt mij dat er andere eisen gesteld worden aan code signing certificaten dan aan Web PKI certificaten. Bij dat laatste is er inderdaad sprake van de minstens 64 bits eis, maar het zou goed kunnen dat dit niet vereist is voor code signing certificaten en dus helemaal niet hoeft voor het extension signing certificaat.

PKI Overheid heeft zich net als alle andere partijen zoals Apple en Google, die niet 4000 maar enkele honderdduizenden certificaten moesten vervangen, gewoon te houden aan deze eis. Alleen in tegenstelling tot Apple en Google lijkt het de Nederlandse overheid een goed idee om er zo lang mogelijk over te doen om de certificaten te vervangen (of zou het echt niet sneller kunnen?). Dat geeft te denken wat er zou gebeuren als een van de intermediates zou worden ingetrokken door bijvoorbeeld een key compromise, zou het dan opeens wel snel kunnen?

Er zijn verschillen tussen TLS server certificaten en code signing certificaten, maar de reden om CSP's (Certificate Service Providers), vóór ondertekening, een random waarde aan een certificaat te laten toevoegen, is voor elk certificaat hetzelfde.

Dat is namelijk om te voorkomen dat, indien een aanvrager een hash collision gevonden heeft, deze kan bewerkstelligen dat die hash-waarde in de digitale handtekening van de CSP onder het certificaat zal worden gebruikt. Daarmee kan de aanvrager een ander certificaat maken dat geldig is omdat de handtekening van de CSP hetzelfde is (en klopt). Dit wordt uitgelegd in https://cabforum.org/2016/03/31/ballot-164/. Met andere woorden: als een random waarde (ongeacht of deze in het serienummer zit of ergens anders in de te ondertekenen blob) belangrijk is, zou dat m.i. voor alle soorten digitale certificaten moeten gelden. En als die random waarde uit tenminste 64 bits zou moeten bestaan (los van het feit dat ik nergens kan vinden waarom 64 en niet meer of minder), dan zie ik niet in waarom dat niet voor alle soorten digitale certificaten zou moeten gelden.

De laatstgenoemde ballot leidde overigens tot de volgende wijziging in nieuwe Baseline Requirements:

M.b.t. concrete eisen aan code signing certificaten, het volgende.

Het CABforum heeft een voorstel geschreven (https://cabforum.org/wp-content/uploads/Code-Signing-Requirements-2015-11-19.pdf) waarin het m.b.t. de eisen aan het serienummer verwijst naar de "Baseline Requirements" (zie https://cabforum.org/baseline-requirements-documents/). Bij de stemming daarvoor is dit voorstel echter afgewezen (https://cabforum.org/2015/12/17/ballot-158/), naar verluidt omdat "some forum members felt code signing was not in scope with the Forum’s charter" (zie https://casecurity.org/2016/07/20/minimum-requirements-for-code-signing-certificates/).

Daarna heeft de "CA Security Council" dat document alsnog aangenomen als standaard (https://casecurity.org/wp-content/uploads/2016/09/Minimum-requirements-for-the-Issuance-and-Management-of-code-signing.pdf), met de opmerking "Microsoft also supports the document and has added the requirement to use the new standard for code signing certificates by February 1, 2017" (http://social.technet.microsoft.com/wiki/contents/articles/31633.microsoft-trusted-root-program-requirements.aspx).

Vanuit de pagina met laatstgenoemde URL verwijst Microsoft in 3.14, via https://aka.ms/csbr (ik heb http in https veranderd) weer naar https://casecurity.org/resources/:
Dat lijk mij een niet te negeren standaard dus. Uit https://casecurity.org/wp-content/uploads/2016/09/Minimum-requirements-for-the-Issuance-and-Management-of-code-signing.pdf:
Met andere woorden, voor de eisen aan het serienummer verwijst ook dit document naar de "Baseline Requirements" van het CA/Browser Forum.

Mozilla houdt zich hier duidelijk niet aan, ook niet bij de uitgifte van end-entity code signing certificaten. Eerder en gisteravond heb ik een stel Firefox add-ons/extensions gedownload (die bijv. overboekingen zouden kunnen manipuleren tijdens internetbankieren, en waarvan het dus op z'n minst noodzakelijk is dat je weet wie die extensie gemaakt heeft - los van of die partij betrouwbaar is). De resultaten:


De lijst hierboven heb ik gesorteerd op serienummer van het certificaat. Opvallend is dat er een relatie lijkt te bestaan tussen het serienummer en de vervaldatum. Ook doordat de eerste byte steeds 0x15 is, lijkt het er wel heel sterk op dat er geen sprake is van 64-bit randomness (helemaal uitsluiten kan ik dat niet, zie https://dilbert.com/strip/2001-10-25).

Overigens zijn alle extensies gisteravond gedownload, behalve "HTTPS Everywhere (oud)" op 20190506 en "HTTPS Everywhere hotfix" op 20190505.

Duidelijk is dat Mozilla zich niet aan de "gangbare" standaard houdt. Dit leidt, voor zover ik weet, niet tot een beveiligingsrisico. Maar ik vind het wel vreemd dat als andere organisaties (zoals PKI overheid en gebruikers van die certificaten) zich wel exact aan regels moeten houden, Mozilla meent dat niet te hoeven doen.

Bitwiper, welke CA (if any) heeft de certificaten die je hierboven omschrijft uitgegeven?

Mozilla zelf.

Het root certificaat, dat in de Windows versie van Firefox hardcoded in xul.dll is opgenomen, wordt niet getoond in de Firefox certificate manager (zie ook https://www.security.nl/posting/607930/Firefox+add-on+cert+issues#posting607932).

Het lijkt alleen anders te werken dan ik vermoedde: uit https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Distribution maak ik op dat Mozilla voor elke extensie een sleutelpaar en bijbehorend certificaat genereert en Mozilla de extensie ondertekent (in plaats van de auteur). De logica hiervan ontgaat me: waarom gebruikt Mozilla een dedicated code signing cert per extensie, en belangrijker, hoe weten Firefox-extensie gebruikers dat de unsigned code daadwerkelijk afkomstig is van de kennelijke auteur?

Zodra ik tijd heb ga ik hier maar eens verder induiken denk ik.

Volgens mij is Mozilla zelf geen CA.
De vraag is of een dergelijk certificaat onder de scope valt van de "basic requirements" die de minimale entropie-eis stelt.

En zo kunnen onverlaten en commercie per extentie gaan cert-fingerprinten.
Er is gewoon te veel excessieve info proliferatie.
Dat gaat ook bij certificering en encryptie ons nog eens lekker opbreken.
Wat denk je, beste Bitwiper?
#sockpuppet