Bemærk oversætter: af hensyn til læserne er datoer angivet i Moskva-tid
Vi gik for nylig glip af udløbet af et af de certifikater, der blev brugt til at signere tilføjelser. Dette resulterede i, at tilføjelser blev deaktiveret for brugere. Nu hvor problemet for det meste er løst, vil jeg gerne dele detaljerne om, hvad der skete, og det arbejde, der blev udført.
Baggrund: tilføjelser og underskrifter
Installerede tilføjelser skal have digital signatur, som beskytter brugere mod ondsindede tilføjelser og kræver minimal gennemgang af tilføjelser af Mozilla-personale. Vi indførte dette krav i 2015, fordi vi oplevede alvorlige problemer med ondsindede tilføjelser.
Sådan fungerer det: Hver kopi af Firefox indeholder et "rodcertifikat". Nøglen til denne "rod" er gemt i Hardware Security Module (HSM)uden netværksadgang. Hvert par år underskrives et nyt "mellemcertifikat" med denne nøgle, som bruges ved signering af tilføjelser. Når en udvikler indsender en tilføjelse, opretter vi et midlertidigt "slutcertifikat" og underskriver det ved hjælp af et mellemcertifikat. Selve tilføjelsen underskrives derefter med det endelige certifikat. Skematisk det ser sådan ud.
Bemærk venligst, at hvert certifikat har et "emne" (som certifikatet er udstedt til) og en "udsteder" (som har udstedt certifikatet). I tilfælde af et rodcertifikat er "emne" = "udsteder", men for andre certifikater er udstederen af certifikatet emnet for det overordnede certifikat, som det er underskrevet af.
En vigtig pointe: hver tilføjelse er underskrevet af et unikt slutcertifikat, men næsten altid er disse slutcertifikater underskrevet af det samme mellemliggende certifikat.
Forfatterens note: Undtagelsen er meget gamle tilføjelser. Dengang brugte man forskellige mellemcertifikater.
Dette mellemliggende certifikat gav problemer: hvert certifikat er gyldigt i en vis periode. Før eller efter denne periode er certifikatet ugyldigt, og browseren vil ikke bruge tilføjelser, der er signeret af dette certifikat. Desværre udløb mellembeviset den 4. maj kl. 4.
Konsekvenserne viste sig ikke umiddelbart. Firefox tjekker ikke signaturerne på installerede tilføjelser konstant, men cirka en gang hver 24 timer, og verifikationstiden er individuel for hver bruger. Som følge heraf oplevede nogle mennesker problemer med det samme, mens andre oplevede problemer meget senere. Vi blev først opmærksomme på problemet omkring det tidspunkt, hvor certifikatet udløb, og begyndte straks at lede efter en løsning.
Reducerer skader
Da vi indså, hvad der var sket, forsøgte vi at forhindre, at situationen blev værre.
For det første holdt de op med at acceptere og underskrive nye tilføjelser. Det nytter ikke at bruge et udløbet certifikat til dette. Når jeg ser tilbage, vil jeg sige, at vi kunne have ladet alt være, som det var. Vi er nu genoptaget med at modtage tillæg.
For det andet sendte de straks en rettelse ud, der forhindrede signaturer i at blive tjekket dagligt. Således reddede vi de brugere, hvis browser endnu ikke havde haft tid til at tjekke tilføjelserne inden for de sidste XNUMX timer. Denne rettelse er nu blevet trukket tilbage og er ikke længere nødvendig.
Parallel drift
I teorien ser løsningen på problemet enkel ud: Opret et nyt gyldigt mellemcertifikat og gensign hver tilføjelse. Desværre virker dette ikke:
- vi kan ikke hurtigt gensignere 15 tilføjelser på én gang, systemet er ikke designet til en sådan belastning
- Når vi har underskrevet tilføjelserne, skal de opdaterede versioner leveres til brugerne. De fleste tilføjelser er installeret fra Mozilla-servere, så Firefox vil finde opdateringer inden for de næste XNUMX timer, men nogle udviklere distribuerer signerede tilføjelser gennem tredjepartskanaler, så brugere bliver nødt til at opdatere sådanne tilføjelser manuelt
I stedet forsøgte vi at udvikle en rettelse, der ville nå alle brugere uden at kræve meget eller ingen handling fra deres side.
Ret hurtigt kom vi til to hovedstrategier, som vi brugte sideløbende:
- Opdater Firefox for at ændre certifikatets gyldighedsperiode. Dette vil få eksisterende tilføjelser til at virke på magisk vis, men vil kræve frigivelse og forsendelse af en ny version af Firefox
- Generer et gyldigt certifikat og overbevis Firefox til at acceptere det i stedet for det eksisterende, der er udløbet
Vi besluttede at bruge den første mulighed først, som så ganske brugbar ud. I slutningen af dagen udgav de en anden rettelse (et nyt certifikat), som vi vil tale om senere.
Udskiftning af et certifikat
Som jeg nævnte ovenfor, var det påkrævet:
- oprette et nyt gyldigt certifikat
- installer det eksternt i Firefox
For at forstå hvorfor dette virker, lad os se nærmere på tilføjelsesbekræftelsesprocessen. Selve tilføjelsen kommer som et sæt filer, inklusive en kæde af certifikater, der bruges til signering. Som følge heraf kan tilføjelsen verificeres, hvis browseren kender rodcertifikatet, som er indbygget i Firefox på byggetidspunktet. Men som vi allerede ved, er mellemcertifikatet udløbet, så det er umuligt at verificere tilføjelsen.
Når Firefox forsøger at bekræfte en tilføjelse, er det ikke begrænset til at bruge certifikaterne indeholdt i selve tilføjelsen. I stedet forsøger browseren at oprette en gyldig certifikatkæde, startende med slutcertifikatet og fortsætter, indtil det kommer til roden. På første niveau starter vi med slutbeviset og finder derefter det certifikat, hvis emne er udstederen af slutbeviset (det vil sige mellembeviset). Typisk leveres dette mellemcertifikat med tilføjelsen, men ethvert certifikat fra browserens lager kan også fungere som dette mellemcertifikat. Hvis vi eksternt kan tilføje et nyt gyldigt certifikat til certifikatlageret, vil Firefox forsøge at bruge det. Situationen før og efter installation af et nyt certifikat.
Efter installation af det nye certifikat vil Firefox have to muligheder, når certifikatkæden valideres: brug det gamle ugyldige certifikat (som ikke virker) eller det nye gyldige certifikat (som vil fungere). Det er vigtigt, at det nye certifikat indeholder samme emnenavn og offentlige nøgle som det gamle certifikat, så dets signatur på det endelige certifikat vil være gyldig. Firefox er smart nok til at prøve begge muligheder, indtil den finder en, der virker, så tilføjelserne bliver testet igen. Bemærk, at dette er den samme logik, som vi bruger til at validere TLS-certifikater.
Forfatterens note: Læsere, der er fortrolige med WebPKI, vil bemærke, at krydscertifikater fungerer på nøjagtig samme måde.
Det fantastiske ved denne rettelse er, at det ikke kræver, at du gensigner eksisterende tilføjelser. Så snart browseren modtager det nye certifikat, vil alle tilføjelser fungere igen. Den resterende udfordring er at levere det nye certifikat til brugerne (automatisk og eksternt), samt at få Firefox til at gentjekke deaktiverede tilføjelser.
Normandiet og forskningssystemet
Ironisk nok er dette problem løst af en speciel tilføjelse kaldet "system". For at udføre forskning udviklede vi et system kaldet Normandiet, der leverer forskning til brugerne. Disse undersøgelser udføres automatisk i browseren og har forbedret adgang til Firefoxs interne API'er. Forskning kan tilføje nye certifikater til certifikatlageret.
Forfatterens note: Vi tilføjer ikke et certifikat med særlige privilegier; det er signeret af rodcertifikatet, så Firefox stoler på det. Vi tilføjer det blot til puljen af certifikater, der kan bruges af browseren.
Så løsningen er at lave en undersøgelse:
- installation af det nye certifikat, vi oprettede til brugere
- tvinger browseren til at kontrollere deaktiverede tilføjelser igen, så de fungerer igen
"Men vent," siger du, "tilføjelser virker ikke, hvordan kan jeg starte en systemtilføjelse?" Lad os underskrive det med et nyt certifikat!
At sætte det hele sammen... hvorfor tager det så lang tid?
Så planen: udsted et nyt certifikat for at erstatte det gamle, opret et systemtilføjelse og installer det til brugere via Normandiet. Problemerne begyndte som sagt den 4. maj klokken 4:00, og allerede klokken 12:44 samme dag, mindre end 9 timer senere, sendte vi en rettelse til Normandiet. Det tog yderligere 6-12 timer for det at nå alle brugere. Slet ikke dårligt, men folk på Twitter spørger, hvorfor vi ikke kunne have handlet hurtigere.
For det første tog det tid at udstede et nyt mellemcertifikat. Som jeg nævnte ovenfor, er nøglen til rodcertifikatet gemt offline i hardwaresikkerhedsmodulet. Dette er godt ud fra et sikkerhedssynspunkt, da roden bruges meget sjældent og bør være pålideligt beskyttet, men det er lidt ubelejligt, når du akut skal underskrive et nyt certifikat. En af vores ingeniører måtte rejse til HSM-lageret. Så var der mislykkede forsøg på at udstede det korrekte certifikat, og hvert forsøg kostede en eller to timer brugt på at teste.
For det andet tog udviklingen af systemtilføjelsen noget tid. Konceptuelt er det meget enkelt, men selv simple programmer kræver omhu. Vi ville sikre os, at vi ikke gjorde situationen værre. Forskning skal testes, før den sendes til brugerne. Derudover skal tilføjelsen signeres, men vores tilføjelsessigneringssystem var deaktiveret, så vi måtte finde en løsning.
Endelig, når vi havde forskningen klar til indsendelse, tog implementeringen tid. Browseren tjekker for Normandiet-opdateringer hver 6. time. Ikke alle computere er altid tændt og forbundet til internettet, så det vil tage tid, før rettelsen spredes til brugerne.
Afsluttende trin
Undersøgelsen burde løse problemet for de fleste brugere, men er ikke tilgængelig for alle. Nogle brugere kræver en særlig tilgang:
- brugere, der har deaktiveret forskning eller telemetri
- brugere af Android-versionen (Fennec), hvor forskning slet ikke understøttes
- brugere af brugerdefinerede builds af Firefox ESR i virksomheder, hvor telemetri ikke kan aktiveres
- brugere, der sidder bag MitM-proxies, da vores tilføjelsesinstallationssystem bruger nøglepinning, hvilket ikke virker med sådanne proxyer
- brugere af ældre versioner af Firefox, der ikke understøtter forskning
Vi kan ikke gøre noget ved sidstnævnte kategori af brugere – de bør stadig opdatere til den nye version af Firefox, fordi forældede har alvorlige uoprettede sårbarheder. Vi ved, at nogle mennesker bliver på ældre versioner af Firefox, fordi de ønsker at køre gamle tilføjelser, men mange af de gamle tilføjelser er allerede blevet overført til nyere versioner af browseren. Til andre brugere har vi udviklet en patch, der installerer et nyt certifikat. Det blev udgivet som en fejlrettelsesudgivelse (oversætterens bemærkning: Firefox 66.0.5), så folk får det - højst sandsynligt allerede fået det - gennem den almindelige opdateringskanal. Hvis du bruger en brugerdefineret build af Firefox ESR, bedes du kontakte din vedligeholder.
Vi forstår, at dette ikke er ideelt. I nogle tilfælde mistede brugere tilføjelsesdata (f.eks. tilføjelsesdata Containere med flere konti).
Denne bivirkning kunne ikke undgås, men vi mener, at vi på kort sigt har valgt den bedste løsning for de fleste brugere. På længere sigt vil vi lede efter andre, mere avancerede arkitektoniske tilgange.
Lektionerne
For det første gjorde vores team et fantastisk stykke arbejde med at skabe og sende en rettelse på mindre end 12 timer efter, at problemet blev opdaget. Som en, der deltog i møderne, kan jeg sige, at i denne vanskelige situation arbejdede folk meget hårdt, og meget lidt tid blev spildt.
Det er klart, at intet af dette skulle være sket overhovedet. Det er klart umagen værd at justere vores processer for at reducere sandsynligheden for sådanne hændelser og gøre udbedring lettere.
I næste uge vil vi offentliggøre en officiel obduktion og en liste over ændringer, vi har til hensigt at foretage. Indtil videre vil jeg dele mine tanker. For det første skal der være en bedre måde at overvåge status for, hvad der er en potentiel tidsindstillet bombe. Vi skal være sikre på, at vi ikke kommer i en situation, hvor en af dem pludselig virker. Vi arbejder stadig på detaljerne, men det er som minimum nødvendigt at tage højde for alle sådanne ting.
For det andet har vi brug for en mekanisme til hurtigt at levere opdateringer til brugerne, selv når – især når – alt andet fejler. Det var dejligt, at vi kunne bruge "research"-systemet, men det er et uperfekt værktøj og har nogle uønskede bivirkninger. Vi ved især, at mange brugere har automatiske opdateringer slået til, men foretrækker ikke at deltage i forskning (jeg indrømmer, jeg har dem også slået fra!). Samtidig har vi brug for en måde at sende opdateringer til brugerne på, men uanset den interne tekniske implementering, skal brugerne kunne abonnere på opdateringer (inklusive hotfixes), men fravælge alt andet. Derudover skulle opdateringskanalen være mere lydhør, end den er nu. Selv den 6. maj var der stadig brugere, der ikke benyttede sig af hverken rettelsen eller den nye version. Dette problem var allerede blevet arbejdet på, men det, der skete, viste, hvor vigtigt det er.
Til sidst vil vi se nærmere på tilføjelsens sikkerhedsarkitektur for at sikre, at den giver det rigtige sikkerhedsniveau med minimal risiko for at gå i stykker.
I næste uge vil vi se på resultaterne af en mere grundig analyse af, hvad der skete, men i mellemtiden svarer jeg gerne på spørgsmål via e-mail: [e-mail beskyttet]
Kilde: linux.org.ru