Bemærkning fra oversætteren: For at gøre det lettere for læserne er datoerne angivet i Moskva-tid.
For nylig missede vi udløbsdatoen for et af de certifikater, der bruges til at signere udvidelser. Dette førte til, at brugere fik deres udvidelser deaktiveret. Nu, hvor problemerne for det meste er løst, vil jeg gerne fortælle om detaljerne i hændelsen og det udførte arbejde.
Baggrund: Udvidelser og signaturer
Installerede tilføjelser skal have en digital signatur, som beskytter brugere mod skadelige tilføjelser, og kræver minimal kontrol af tilføjelserne fra Mozillas medarbejdere. Vi indførte dette krav i 2015, fordi vi oplevede alvorlige problemer med skadelige tilføjelser.
Sådan fungerer det: Hver kopi af Firefox indeholder "rodcertifikatet". Nøglen til denne "rod" opbevares i en hardware-sikkerhedsmodul (HSM), der ikke har netværksadgang. Hver few år underskrives en ny "mellem-certifikat" med denne nøgle, som anvendes til at signere tilføjelser. Når en udvikler sender en tilføjelse, opretter vi et midlertidigt "slut-certifikat" og underskriver det ved hjælp af mellem-certifikatet. Derefter underskrives selve tilføjelsen med slut-certifikatet. Schematiskt ser det sådan ud.
Bemærk: Hvert certifikat har et "subjekt" (hvortil certifikatet er udstedt) og en "udsteder" (hvem der udstedte certifikatet). I tilfælde af rodcertifikatet er "subjekt" = "udsteder", men for andre certifikater er udstederen af certifikatet subjektet for det overordnede certifikat, som det er underskrevet af.
Et vigtigt punkt: Hver tilføjelse er underskrevet med et unikt slut-certifikat, men næsten altid er disse slut-certifikater underskrevet af det samme mellem-certifikat.
Forfatterens bemærkning: Undtagelsen er meget gamle tilføjelser. I den tid blev der brugt forskellige mellem-certifikater.
Dette mellemliggende certifikat forårsagede problemer: hvert certifikat er gyldigt i en bestemt periode. Før eller efter denne periode er certifikatet ugyldigt, og browseren vil ikke anvende udvidelser, der er signeret med dette certifikat. Desværre udløb gyldigheden af det mellemliggende certifikat den 4. maj kl. 4 om morgenen.
Konsekvenserne viste sig ikke straks. Firefox kontrollerer ikke konstant signaturerne på de installerede udvidelser, men cirka hver 24. time, og kontroltidspunktet varierer for hver bruger. Som følge heraf oplevede nogle personer problemer med det samme, mens andre først langt senere. Vi fik første gang kendskab til problemet omkring det tidspunkt, hvor certifikatets gyldighed udløb, og begyndte straks at lede efter en løsning.
Reducerer skaden
Så snart vi forstod, hvad der var sket, forsøgte vi at forhindre forværring af situationen.
For det første stoppede vi med at acceptere og underskrive nye udvidelser. Der var ingen mening i at bruge et udløbet certifikat til dette. Når jeg ser tilbage, ville jeg sige, at vi måske kunne have ladet alt være som det var. Nu er modtagelsen af udvidelser genoptaget.
For det andet sendte vi straks en rettelse ud, der forhindrede den daglige kontrol af signaturer. På denne måde reddede vi de brugere, hvis browser ikke havde nået at kontrollere udvidelserne i de sidste 24 timer. Denne rettelse er nu tilbagekaldt, da der ikke længere er behov for den.
Parallel drift
Teoretisk set ser løsningen på problemet enkel ud: vi opretter et nyt gyldigt mellemliggende certifikat og genunderskriver hver udvidelse. Desværre vil dette ikke fungere:
- vi kan ikke hurtigt genunderskrive 15.000 udvidelser på én gang, systemet er ikke designet til en sådan belastning
- efter at vi har underskrevet udvidelserne, skal de opdaterede versioner leveres til brugerne. De fleste udvidelser installeres fra Mozillas servere, så inden for de næste 24 timer vil Firefox finde opdateringerne, men nogle udviklere distribuerer signerede udvidelser gennem tredjepartskanaler, så brugerne ville være nødt til at opdatere sådanne udvidelser manuelt
I stedet forsøgte vi at udvikle en rettelse, der ville nå ud til alle brugere, uden at det krævede (eller næsten ikke krævede) handling fra deres side.
Ret hurtigt nåede vi frem til to hovedstrategier, som vi anvendte parallelt:
- Opdater Firefox for at ændre certifikatets gyldighedsperiode. Dette vil få eksisterende udvidelser til at fungere igen magisk, men kræver udgivelse og levering af en ny Firefox-udgave.
- Opret et gyldigt certifikat og på en eller anden måde overbevis Firefox om at acceptere det i stedet for det eksisterende, hvis gyldighedsperiode er udløbet.
Vi besluttede først at anvende den første løsning, som så ud til at være fuldt ud fungerende. I slutningen af dagen udgav vi også den anden opdatering (det nye certifikat), som vi vil tale om senere.
Udskiftning af certifikat
Som nævnt tidligere krævedes:
- at der blev oprettet et nyt gyldigt certifikat
- at det blev installeret fjernadgang i Firefox
For at forstå hvorfor dette ville fungere, lad os se nærmere på processen med at kontrollere udvidelsen. Selve udvidelsen leveres som et sæt filer, herunder en kæde af certifikater, der bruges til at signere. Som et resultat kan udvidelsen verificeres, hvis browseren kender rodcertifikatet, som integreres i Firefox under opbygningen. Men som vi allerede ved, er det mellemliggende certifikat udløbet, så udvidelsen kan ikke verificeres.
Når Firefox forsøger at kontrollere en udvidelse, begrænser den sig ikke til at bruge de certifikater, der er indeholdt i selve udvidelsen. I stedet prøver browseren at oprette en gyldig kæde af certifikater, der starter fra det endelige certifikat og fortsætter, indtil den når roden. På det første niveau begynder vi med det endelige certifikat og finder derefter certifikatet, hvis emne er udgiveren af det endelige certifikat (dvs. det mellemliggende certifikat). Dette mellemliggende certifikat leveres normalt sammen med udvidelsen, men enhver certifikat fra browserens opbevaring kan også spille denne rolle. Hvis vi kan tilføje et nyt gyldigt certifikat i certifikatbeholdningen fjernadgang, vil Firefox forsøge at bruge det. Situationen før og efter installationen af det nye certifikat.
Efter installationen af det nye certifikat vil Firefox have to muligheder, når det kontrollerer certifikatkæden: at bruge det gamle ugyldige certifikat (som ikke vil fungere) eller det nye gyldige certifikat (som vil fungere). Det er vigtigt, at det nye certifikat indeholder det samme subjekt navn og offentlige nøgle som det gamle certifikat, således at dets underskrift på det endelige certifikat vil være gyldig. Firefox er smart nok til at prøve begge muligheder, indtil det finder en, der fungerer, så tillæg vil igen blive godkendt. Bemærk, at dette er den samme logik, som vi anvender til at verificere TLS-certifikater.
Forfatterens note: læsere, der er bekendt med WebPKI, vil bemærke, at krydsets certifikater fungerer på samme måde.
Det mest fantastiske ved denne løsning er, at den ikke kræver, at eksisterende tillæg genunderskrives. Så snart browseren modtager det nye certifikat, vil alle tillæg igen fungere. Der er stadig en kompleksitet i at levere det nye certifikat til brugerne (automatisk og fjernstyring) samt få Firefox til at genkontrollere de deaktiverede tillæg.
Normandy og forskningssystemet
Ironisk nok løser et specielt tillæg, kaldet 'system', dette problem. For at udføre forskning har vi udviklet et system ved navn Normandy, som leverer forskning til brugerne. Disse undersøgelser udføres automatisk i browseren og har udvidet adgang til interne API'er til Firefox. Forskningen kan tilføje nye certifikater til certifikatlageret.
Forfatterens note: vi tilføjer ikke et certifikat med nogle særlige privilegier; det er underskrevet med et rodcertifikat, så Firefox stoler på det. Vi tilføjer det blot til puljen af certifikater, der kan anvendes af browseren.
Derfor består løsningen i at skabe en undersøgelse:
- der installerer det nye certifikat, vi har lavet til brugerne
- der får browseren til at genkontrollere de deaktiverede tillæg, så de kan fungere igen
"Men vent," vil du sige, "tillæggene fungerer jo ikke; hvordan kan man starte et systemtillæg?" Lad os underskrive det med det nye certifikat!
Samler alt... hvorfor tager det så lang tid?
Så planen er: at udgive et nyt certifikat til at erstatte det gamle, skabe et systemtilskud og installere det til brugerne via Normandy. Problemerne begyndte, som jeg nævnte, den 4. maj kl. 4:00, og allerede kl. 12:44 samme dag, mindre end 9 timer senere, sendte vi en rettelse til Normandy. Det tog yderligere 6-12 timer for det at nå ud til alle brugerne. Det er allerede godt, men brugere på Twitter spørger, hvorfor vi ikke kunne handle hurtigere.
For det første tog det tid at udgive det nye mellemcertifikat. Som jeg nævnte tidligere, er nøglen til rodcertifikatet opbevaret offline i en hardware-sikkerhedsmodul. Det er godt fra et sikkerhedssynspunkt, da roden bruges meget sjældent og skal beskyttes pålideligt, men det er lidt vanskeligere, når man hurtigt skal underskrive et nyt certifikat. En af vores ingeniører måtte tage til HSM-lageret. Derefter var der mislykkede forsøg på at udstede det rigtige certifikat, og hvert forsøg kostede en til to timer, der blev brugt på testning.
For det andet tog udviklingen af systemtilskuddet noget tid. Konceptuelt er det meget simpelt, men selv enkle programmer kræver omhu. Vi ville sikre os, at vi ikke gjorde situationen endnu værre. Undersøgelsen skal testes, før den sendes til brugerne. Desuden skal tilskuddet underskrives, men vores system til at underskrive tilskud var deaktiveret, så vi måtte finde en omvej.
Endelig, efter at vi havde forberedt undersøgelsen til afsendelse, tog udrulningen tid. Browseren tjekker for Normandy-opdateringer hver 6. time. Ikke alle computere er konstant tændt og tilsluttet internettet, så det tager tid for rettelsen at sprede sig blandt brugerne.
Afsluttende trin
Undersøgelsen skal rette problemet for de fleste brugere, men er ikke tilgængelig for alle. Nogle brugere kræver en særlig tilgang:
- brugere, der har deaktiveret undersøgelser eller telemetri
- brugere af Android-versionen (Fennec), hvor undersøgelser slet ikke understøttes
- brugere af tilpassede versioner af Firefox ESR på virksomheder, hvor det er umuligt at aktivere telemetri
- brugere, der sidder bag en MitM-proxy, da vores system til installation af addons bruger key pinning, som ikke fungerer med sådanne proxyer
- brugere af forældede versioner af Firefox, som ikke understøtter opdateringer
Vi kan ikke gøre noget ved den sidste kategori af brugere — de bør stadig opdatere til den nyeste version af Firefox, fordi de forældede har alvorlige ubearbejdede sårbarheder. Vi ved, at nogle mennesker forbliver på gamle versioner af Firefox, fordi de ønsker at køre gamle addons, men mange af de gamle addons er allerede portet til nye versioner af browseren. For andre brugere har vi udviklet et patch, som vil installere et nyt certifikat. Det blev udgivet som en bugfix-release (øversætterens bemærkning: Firefox 66.0.5), så folk vil modtage det — de fleste har allerede modtaget det — gennem den normale opdateringskanal. Hvis du bruger en specialbygget Firefox ESR, kontakt venligst din vedligeholder.
Vi forstår, at alt dette ikke er perfekt. I nogle tilfælde har brugere mistet data fra addons (for eksempel data fra addon Multi-Account Containers).
Denne bivirkning kunne ikke undgås, men vi mener, at vi i det korte løb har valgt den bedste løsning for de fleste brugere. I det lange løb vil vi se efter andre, mere avancerede arkitektoniske tilgange.
Undervisning
For det første har vores team gjort et fantastisk stykke arbejde med at oprette og sende en løsning på mindre end 12 timer efter opdagelsen af problemet. Som en der deltog i møderne, kan jeg sige, at folk arbejdede meget hårdt i denne vanskelige situation, og der blev brugt meget lidt tid på unødvendige aktiviteter.
Det er klart, at dette overhovedet ikke skulle have været sket. Det er nødvendigt at justere vores processer for at mindske sandsynligheden for sådanne hændelser og lette genoprettelsen af konsekvenserne.
I næste uge vil vi offentliggøre den officielle post-mortem og en liste over de ændringer, vi planlægger at gennemføre. Indtil da vil jeg dele mine tanker. For det første bør der være en bedre måde at overvåge status på det, der er en potentiel tidsindstillet bombe. Vi skal sikre os, at vi ikke ender i en situation, hvor en af dem pludselig aktiveres. Vi arbejder stadig på detaljerne, men i det mindste er det nødvendigt at lave en opgørelse over alle disse ting.
For det andet er der behov for en hurtig leveringsmekanisme til opdateringer til brugerne, selv når – især når – alt andet ikke fungerer. Det var fantastisk, at vi kunne bruge systemet til 'undersøgelser', men det er et ufuldkomment værktøj, og det har nogle uønskede bivirkninger. Især ved vi, at mange brugere har automatisk opdatering aktiveret, men de ville helst ikke deltage i undersøgelser (jeg må indrømme, at jeg også har deaktiveret dem!). Samtidig har vi brug for en måde at sende opdateringer til brugerne, men uanset hvordan den interne tekniske implementering er, skal brugerne have mulighed for at tilmelde sig opdateringer (inklusive hurtigrettelser) men fravælge alt andet. Desuden bør opdateringskanalen være mere responsiv, end den er nu. Selv den 6. maj var der stadig brugere, der ikke havde benyttet sig af hverken rettelsen eller den nye version. Vi har allerede arbejdet på dette problem, men hvad der skete, viste, hvor vigtigt det er.
Endelig vil vi se nærmere på sikkerhedsarkitekturen for tillæg for at sikre, at den leverer et passende sikkerhedsniveau med minimal risiko for at ødelægge noget.
Næste uge vil vi gennemgå resultaterne af en mere grundig analyse af det skete, og indtil da vil jeg være glad for at besvare spørgsmål via e-mail: ekr-blog@mozilla.com
Kilde: linux.org.ru
