Opomba prevajalec: za udobje bralcev so datumi navedeni po moskovskem času
Nedavno smo zamudili potek veljavnosti enega od potrdil, ki se uporablja za podpisovanje dodatkov. Zaradi tega so bili dodatki za uporabnike onemogočeni. Zdaj, ko je bila težava večinoma odpravljena, bi rad delil podrobnosti o tem, kaj se je zgodilo in opravljenem delu.
Ozadje: dodatki in podpisi
Nameščeni dodatki morajo imeti digitalni podpis, ki ščiti uporabnike pred zlonamernimi dodatki in zahteva minimalen pregled dodatkov s strani Mozillinega osebja. To zahtevo smo uvedli leta 2015, ker smo doživljali resne težave z zlonamernimi dodatki.
Kako deluje: Vsaka kopija Firefoxa vsebuje "korensko potrdilo". Ključ do tega "korena" je shranjen v Varnostni modul strojne opreme (HSM)brez dostopa do omrežja. Vsakih nekaj let se s tem ključem podpiše nov »vmesni certifikat«, ki se uporablja pri podpisovanju dodatkov. Ko razvijalec odda dodatek, ustvarimo začasno "končno potrdilo" in ga podpišemo z vmesnim potrdilom. Sam dodatek je nato podpisan s končnim certifikatom. Shematsko izgleda takole.
Upoštevajte, da ima vsako potrdilo "predmet" (komu je bilo izdano potrdilo) in "izdajatelja" (ki je izdalo potrdilo). V primeru korenskega potrdila je "predmet" = "izdajatelj", pri drugih potrdilih pa je izdajatelj potrdila subjekt nadrejenega potrdila, s katerim je podpisano.
Pomembna točka: vsak dodatek je podpisan z edinstvenim končnim potrdilom, vendar so skoraj vedno ta končna potrdila podpisana z istim vmesnim potrdilom.
Opomba avtorja: Izjema so zelo stari dodatki. Takrat so se uporabljali različni vmesni certifikati.
To vmesno potrdilo je povzročalo težave: vsako potrdilo velja določeno obdobje. Pred ali po tem obdobju je potrdilo neveljavno in brskalnik ne bo uporabljal dodatkov, podpisanih s tem potrdilom. Vmesni certifikat je žal potekel 4. maja ob 4. uri zjutraj.
Posledice se niso pokazale takoj. Firefox podpisov nameščenih dodatkov ne preverja nenehno, ampak približno enkrat na 24 ur, čas preverjanja pa je za vsakega uporabnika individualen. Posledično so nekateri ljudje imeli težave takoj, drugi pa veliko kasneje. Težave smo prvič izvedeli v času, ko je certifikat potekel in takoj začeli iskati rešitev.
Zmanjšanje škode
Ko smo ugotovili, kaj se je zgodilo, smo poskušali preprečiti, da bi se situacija poslabšala.
Najprej so prenehali sprejemati in podpisovati nove dodatke. Za to nima smisla uporabljati potečenega certifikata. Če pogledam nazaj, bi rekel, da bi lahko pustili vse tako, kot je bilo. Zdaj smo ponovno začeli sprejemati dodatke.
Drugič, takoj so poslali popravek, ki je preprečil vsakodnevno preverjanje podpisov. Tako smo rešili tiste uporabnike, katerih brskalnik v zadnjih XNUMX urah še ni imel časa preveriti dodatkov. Ta popravek je bil zdaj umaknjen in ni več potreben.
Vzporedno delovanje
V teoriji je rešitev problema videti preprosta: ustvarite novo veljavno vmesno potrdilo in znova podpišite vsak dodatek. Na žalost to ne bo delovalo:
- ne moremo na hitro prepodpisati 15 tisoč dodatkov naenkrat, sistem ni zasnovan za takšno obremenitev
- Ko podpišemo dodatke, je treba posodobljene različice dostaviti uporabnikom. Večina dodatkov je nameščenih iz strežnikov Mozilla, tako da bo Firefox našel posodobitve v naslednjih XNUMX urah, vendar nekateri razvijalci distribuirajo podpisane dodatke prek kanalov tretjih oseb, zato bi morali uporabniki takšne dodatke posodobiti ročno
Namesto tega smo poskušali razviti popravek, ki bi dosegel vse uporabnike, ne da bi zahtevali veliko ali nič ukrepanja z njihove strani.
Zelo hitro smo prišli do dveh glavnih strategij, ki smo ju uporabljali vzporedno:
- Posodobite Firefox, da spremenite obdobje veljavnosti potrdila. S tem bodo obstoječi dodatki čarobno spet delovali, vendar bo treba izdati in poslati novo različico Firefoxa
- Ustvari veljavno potrdilo in nekako prepričaj Firefox, da ga sprejme namesto obstoječega, ki je potekel
Odločili smo se, da najprej uporabimo prvo možnost, ki je izgledala precej izvedljiva. Konec dneva so izdali drugi popravek (novo potrdilo), o katerem bomo govorili kasneje.
Zamenjava certifikata
Kot sem omenil zgoraj, je bilo potrebno:
- ustvarite novo veljavno potrdilo
- namestite na daljavo v Firefox
Da bi razumeli, zakaj to deluje, si podrobneje oglejmo postopek preverjanja dodatkov. Sam dodatek je na voljo kot niz datotek, vključno z verigo potrdil, ki se uporabljajo za podpisovanje. Posledično je dodatek mogoče preveriti, ali brskalnik pozna korensko potrdilo, ki je vgrajeno v Firefox ob gradnji. Kot že vemo, pa je vmesnemu certifikatu potekla veljavnost, zato dodatka ni mogoče preveriti.
Ko Firefox poskuša preveriti dodatek, ni omejen na uporabo potrdil, ki jih vsebuje sam dodatek. Namesto tega poskuša brskalnik ustvariti veljavno verigo potrdil, začenši s končnim potrdilom in nadaljuje, dokler ne pride do korena. Na prvi stopnji začnemo s končnim potrdilom in nato poiščemo potrdilo, katerega predmet je izdajatelj končnega potrdila (torej vmesno potrdilo). Običajno je to vmesno potrdilo priloženo dodatku, vendar lahko kot to vmesno potrdilo služi tudi katero koli potrdilo iz pomnilnika brskalnika. Če lahko na daljavo dodamo novo veljavno potrdilo v shrambo potrdil, ga bo Firefox poskusil uporabiti. Stanje pred in po namestitvi novega certifikata.
Po namestitvi novega potrdila bo imel Firefox pri preverjanju verige potrdil dve možnosti: uporabiti staro neveljavno potrdilo (ki ne bo delovalo) ali novo veljavno potrdilo (ki bo delovalo). Pomembno je, da novo potrdilo vsebuje isto ime subjekta in javni ključ kot staro potrdilo, zato bo njegov podpis na končnem potrdilu veljaven. Firefox je dovolj pameten, da preizkusi obe možnosti, dokler ne najde tiste, ki deluje, zato se dodatki znova preizkusijo. Upoštevajte, da je to ista logika, ki jo uporabljamo za preverjanje potrdil TLS.
Opomba avtorja: Bralci, ki poznajo WebPKI, bodo opazili, da navzkrižna potrdila delujejo na povsem enak način.
Odlična stvar pri tem popravku je, da ne zahteva ponovnega podpisa obstoječih dodatkov. Takoj ko brskalnik prejme novo potrdilo, bodo vsi dodatki spet delovali. Preostali izziv je dostaviti novo potrdilo uporabnikom (samodejno in na daljavo) ter prepričati Firefox, da ponovno preveri onemogočene dodatke.
Normandija in raziskovalni sistem
Ironično, to težavo rešuje poseben dodatek, imenovan "sistem". Za izvajanje raziskav smo razvili sistem, imenovan Normandy, ki zagotavlja raziskave uporabnikom. Te študije se samodejno izvajajo v brskalniku in imajo izboljšan dostop do notranjih API-jev Firefoxa. Raziskave lahko dodajo nova potrdila v shrambo potrdil.
Opomba avtorja: Ne dodajamo certifikata s posebnimi privilegiji; podpisan je s korenskim potrdilom, zato mu Firefox zaupa. Enostavno ga dodamo v skupino potrdil, ki jih lahko uporablja brskalnik.
Rešitev je torej ustvariti študijo:
- namestitev novega potrdila, ki smo ga ustvarili za uporabnike
- prisiljevanje brskalnika, da ponovno preveri onemogočene dodatke, da ponovno delujejo
"Ampak počakajte," pravite, "dodatki ne delujejo, kako naj zaženem sistemski dodatek?" Podpišimo ga z novim certifikatom!
Če vse skupaj sestavim... zakaj traja tako dolgo?
Torej načrt: izdati nov certifikat, ki bo zamenjal starega, ustvariti sistemski dodatek in ga namestiti uporabnikom preko Normandyja. Težave so se, kot rečeno, začele 4. maja ob 4. uri, že ob 00 istega dne, manj kot 12 ur kasneje, pa smo poslali popravek v Normandijo. Trajalo je še 44-9 ur, da je dosegel vse uporabnike. Sploh ni slabo, a ljudje na Twitterju sprašujejo, zakaj nismo mogli ukrepati hitreje.
Najprej je bil potreben čas za izdajo novega vmesnega potrdila. Kot sem omenil zgoraj, je ključ do korenskega potrdila shranjen brez povezave v varnostnem modulu strojne opreme. To je z varnostnega vidika dobro, saj se root uporablja zelo redko in bi moral biti zanesljivo zaščiten, vendar je nekoliko neprijetno, ko morate nujno podpisati novo potrdilo. Eden od naših inženirjev je moral odpotovati v skladišče HSM. Potem so bili neuspešni poskusi izdaje pravega potrdila in vsak poskus je stal eno ali dve uri testiranja.
Drugič, razvoj sistemskega dodatka je trajal nekaj časa. Konceptualno je zelo preprost, vendar tudi preprosti programi zahtevajo skrb. Želeli smo se prepričati, da situacije ne poslabšamo. Raziskave je treba testirati, preden jih pošljemo uporabnikom. Poleg tega mora biti dodatek podpisan, vendar je bil naš sistem za podpisovanje dodatkov onemogočen, zato smo morali poiskati rešitev.
Nazadnje, ko smo imeli raziskavo pripravljeno za oddajo, je uvedba trajala nekaj časa. Brskalnik vsakih 6 ur preveri, ali so na voljo posodobitve Normandije. Vsi računalniki niso vedno vklopljeni in povezani z internetom, zato bo trajalo nekaj časa, da se popravek razširi med uporabnike.
Zadnji koraki
Raziskava bi morala odpraviti težavo za večino uporabnikov, vendar ni na voljo vsem. Nekateri uporabniki potrebujejo poseben pristop:
- uporabniki, ki imajo onemogočeno raziskovanje ali telemetrijo
- uporabniki različice Android (Fennec), kjer raziskovanje sploh ni podprto
- uporabniki različic Firefox ESR po meri v podjetjih, kjer telemetrije ni mogoče omogočiti
- uporabniki, ki sedijo za proxyji MitM, saj naš sistem za namestitev dodatkov uporablja pripenjanje ključev, ki s takimi proxyji ne deluje
- uporabniki starejših različic Firefoxa, ki ne podpirajo raziskovanja
Glede slednje kategorije uporabnikov ne moremo storiti ničesar – še vedno bi morali posodobiti na novo različico Firefoxa, ker imajo zastarele resne nepopravljene ranljivosti. Vemo, da nekateri ljudje ostajajo na starejših različicah Firefoxa, ker želijo zagnati stare dodatke, vendar je veliko starih dodatkov že prenesenih v novejše različice brskalnika. Za druge uporabnike smo razvili popravek, ki bo namestil nov certifikat. Izdana je bila kot izdaja s popravkom napak (opomba prevajalca: Firefox 66.0.5), tako da ga bodo ljudje dobili - najverjetneje so ga že dobili - prek običajnega kanala za posodabljanje. Če uporabljate različico Firefox ESR po meri, se obrnite na svojega vzdrževalca.
Zavedamo se, da to ni idealno. V nekaterih primerih so uporabniki izgubili podatke o dodatkih (na primer podatke o dodatkih Zabojniki z več računi).
Temu stranskemu učinku se ni bilo mogoče izogniti, vendar menimo, da smo kratkoročno izbrali najboljšo rešitev za večino uporabnikov. Dolgoročno pa bomo iskali druge, naprednejše arhitekturne pristope.
Lekcije
Prvič, naša ekipa je opravila neverjetno delo, ustvarila in poslala popravek v manj kot 12 urah po odkritju težave. Kot nekdo, ki je bil prisoten na srečanjih, lahko rečem, da so ljudje v tej težki situaciji zelo trdo delali in je bilo izgubljenega zelo malo časa.
Očitno se nič od tega sploh ne bi smelo zgoditi. Jasno je, da je vredno prilagoditi naše procese, da zmanjšamo verjetnost takšnih incidentov in olajšamo sanacijo.
Naslednji teden bomo objavili uradno obdukcijo in seznam sprememb, ki jih nameravamo izvesti. Za zdaj bom delil svoje misli. Prvič, obstajati mora boljši način za spremljanje statusa potencialne tempirane bombe. Prepričani moramo biti, da se ne znajdemo v situaciji, ko kateri od njih nenadoma deluje. Podrobnosti še urejamo, a najmanj je treba upoštevati vse take stvari.
Drugič, potrebujemo mehanizem za hitro dostavo posodobitev uporabnikom, tudi ko – še posebej kadar – vse drugo odpove. Odlično je bilo, da smo lahko uporabili sistem "raziskovanje", vendar je nepopolno orodje in ima nekaj neželenih stranskih učinkov. Predvsem vemo, da imajo številni uporabniki vklopljene samodejne posodobitve, a raje ne bi sodelovali v raziskavi (priznam, tudi jaz jih imam izklopljene!). Hkrati potrebujemo način za pošiljanje posodobitev uporabnikom, vendar ne glede na notranjo tehnično izvedbo bi morali imeti uporabniki možnost, da se naročijo na posodobitve (vključno s hitrimi popravki), vendar se odpovejo vsemu drugemu. Poleg tega bi moral biti kanal za posodobitev bolj odziven, kot je zdaj. Tudi 6. maja so bili še uporabniki, ki niso izkoristili niti popravka niti nove različice. Na tem problemu so že delali, toda to, kar se je zgodilo, je pokazalo, kako pomemben je.
Nazadnje si bomo podrobneje ogledali varnostno arhitekturo dodatka, da se prepričamo, da zagotavlja pravo raven varnosti z minimalnim tveganjem, da bi kar koli zlomili.
Naslednji teden si bomo ogledali rezultate temeljitejše analize dogajanja, medtem pa bom z veseljem odgovoril na vprašanja po e-pošti: [e-pošta zaščitena]
Vir: linux.org.ru