Shënim i përkthyesit: për lehtësinë e lexuesve, datat janë dhënë sipas kohës së Moskës
Së fundmi na shpëtoi pa u vënë re skadimi i njërit prej certifikatave që përdoren për nënshkrimin e shtesave. Kjo çoi në çaktivizimin e shtesave te përdoruesit. Tani që problemi është zgjidhur në pjesën më të madhe, dua të tregoj më në hollësi çfarë ndodhi dhe çfarë pune u bë.
Sfondi: shtesat dhe nënshkrimet
Shtesat e instaluara duhet të kenë nënshkrim dixhital, i cili i mbron përdoruesit nga shtesat keqdashëse dhe kërkon një verifikim minimal të shtesave nga punonjësit e Mozilla. Këtë kërkesë e vendosëm në vitin 2015, sepse kishim probleme serioze me shtesat keqdashëse.
Si funksionon: çdo kopje e Firefox përmban një «certifikatë rrënjë». Çelësi i kësaj «rrënje» ruhet në modulin e mbrojtjes harduerike (HSM), i cili nuk ka qasje në rrjet. Çdo disa vite, me këtë çelës nënshkruhet një «certifikatë ndërmjetëse» e re, e cila përdoret për nënshkrimin e shtesave. Kur një zhvillues dërgon një shtesë, ne krijojmë një «certifikatë fundore» të përkohshme dhe e nënshkruajmë atë duke përdorur certifikatën ndërmjetëse. Më pas, me certifikatën fundore nënshkruhet vetë shtesa. Skematikisht, duket kështu.
Vini re: çdo certifikatë ka një «subjekt» (kujt i është lëshuar certifikata) dhe një «lëshues» (kush e ka lëshuar certifikatën). Në rastin e certifikatës rrënjë, «subjekti» = «lëshuesi», por për certifikatat e tjera lëshuesi i certifikatës është subjekti i certifikatës së nivelit më të lartë, nga e cila ajo është nënshkruar.
Pikë e rëndësishme: çdo shtesë nënshkruhet me një certifikatë fundore unike, por pothuajse gjithmonë këto certifikata fundore nënshkruhen nga e njëjta certifikatë ndërmjetëse.
Shënim i autorit: përjashtim bëjnë shtesat shumë të vjetra. Në atë kohë përdoreshin certifikata të ndryshme ndërmjetëse.
Ky certifikatë i ndërmjetëm shkaktoi probleme: çdo certifikatë është e vlefshme vetëm për një periudhë të caktuar. Para ose pas kësaj periudhe, certifikata është e pavlefshme dhe shfletuesi nuk do të përdorë shtojcat e nënshkruara me këtë certifikatë. Fatkeqësisht, vlefshmëria e certifikatës së ndërmjetme skadoi më 4 maj në orën 4 të mëngjesit.
Pasojat nuk u shfaqën menjëherë. Firefox nuk i verifikon vazhdimisht nënshkrimet e shtojcave të instaluara, por afërsisht një herë në 24 orë, dhe koha e kontrollit është individuale për secilin përdorues. Si rezultat, disa përdorues i hasën problemet menjëherë, ndërsa të tjerë shumë më vonë. Për problemin mësuam për herë të parë afërsisht në momentin kur skadoi certifikata dhe menjëherë nisëm të kërkonim një zgjidhje.
Po kufizojmë dëmin
Sapo kuptuam se çfarë kishte ndodhur, u përpoqëm të mos lejonim përkeqësimin e situatës.
Së pari, ndaluam pranimin dhe nënshkrimin e shtojcave të reja. Nuk ka kuptim të përdoret për këtë një certifikatë e skaduar. Duke e parë tani në retrospektivë, do të thosha se gjithçka mund të ishte lënë siç ishte. Tani pranimi i shtojcave është rifilluar.
Së dyti, dërguam menjëherë një korrigjim që parandaloi kontrollin e përditshëm të nënshkrimeve. Kështu, i shpëtuam ata përdorues te të cilët shfletuesi ende nuk kishte arritur t’i kontrollonte shtojcat gjatë 24 orëve të fundit. Tani ky korrigjim është tërhequr, sepse nuk është më i nevojshëm.
Punë paralele
Teorikisht, zgjidhja e problemit duket e thjeshtë: krijojmë një certifikatë të re të vlefshme të ndërmjetme dhe nënshkruajmë sërish çdo shtojcë. Fatkeqësisht, kjo nuk do të funksionojë:
- nuk mund t’i rinënshkruajmë shpejt 15 mijë shtojca njëherësh, sepse sistemi nuk është projektuar për një ngarkesë të tillë
- pasi t’i nënshkruajmë shtojcat, versionet e përditësuara duhet t’u dorëzohen përdoruesve. Shumica e shtojcave instalohen nga serverët e Mozilla, prandaj gjatë 24 orëve të ardhshme Firefox do t’i gjejë përditësimet, por disa zhvillues i shpërndajnë shtojcat e nënshkruara përmes kanaleve të palëve të treta, ndaj përdoruesit do të duhej t’i përditësonin ato manualisht
Në vend të kësaj, u përpoqëm të zhvillonim një korrigjim që do të arrinte te të gjithë përdoruesit, pa kërkuar prej tyre asnjë veprim ose pothuajse asnjë veprim.
Shumë shpejt arritëm te dy strategjitë kryesore, të cilat i përdorëm paralelisht:
- Të përditësonim Firefox-in për të ndryshuar afatin e vlefshmërisë së certifikatës. Kjo do t'i bënte shtesat ekzistuese të funksiononin sërish si me magji, por do të kërkonte publikimin dhe shpërndarjen e një build-i të ri të Firefox
- Të krijonim një certifikatë të vlefshme dhe disi ta bindnim Firefox-in ta pranonte atë në vend të certifikatës ekzistuese, afati i së cilës kishte skaduar
Vendosëm fillimisht të përdornim opsionin e parë, i cili dukej plotësisht i zbatueshëm. Në fund të ditës publikuam edhe zgjidhjen e dytë (certifikatën e re), për të cilën do të flasim më poshtë.
Zëvendësimi i certifikatës
Siç e përmenda më sipër, kërkohej:
- të krijohej një certifikatë e re e vlefshme
- të instalohej ajo nga distanca në Firefox
Për të kuptuar pse kjo do të funksionojë, le të shqyrtojmë më nga afër procesin e verifikimit të shtesës. Vetë shtesa shpërndahet si një grup skedarësh, përfshirë zinxhirin e certifikatave që përdoren për nënshkrim. Si rezultat, shtesa mund të verifikohet nëse shfletuesi e njeh certifikatën rrënjë, e cila integrohet në Firefox gjatë build-it. Megjithatë, siç e dimë tashmë, certifikata ndërmjetëse ka skaduar, ndaj verifikimi i shtesës është i pamundur.
Kur Firefox përpiqet të verifikojë një shtesë, ai nuk kufizohet vetëm te përdorimi i certifikatave që ndodhen brenda vetë shtesës. Në vend të kësaj, shfletuesi përpiqet të krijojë një zinxhir të vlefshëm certifikatash, duke nisur nga certifikata përfundimtare dhe duke vazhduar derisa të arrijë te certifikata rrënjë. Në nivelin e parë niset nga certifikata përfundimtare, e më pas gjendet certifikata, subjekti i së cilës është lëshuesi i certifikatës përfundimtare (pra, certifikata ndërmjetëse). Zakonisht kjo certifikatë ndërmjetëse vjen së bashku me shtesën, por në këtë rol mund të përdoret edhe çdo certifikatë nga depoja e certifikatave të shfletuesit. Nëse arrijmë të shtojmë nga distanca një certifikatë të re të vlefshme në këtë depo, Firefox do të përpiqet ta përdorë atë. Situata para dhe pas instalimit të certifikatës së re.
Pas instalimit të certifikatës së re, Firefox do të ketë dy mundësi kur verifikon zinxhirin e certifikatave: të përdorë certifikatën e vjetër të pavlefshme (e cila nuk do të funksionojë), ose të renë të vlefshme (e cila do të funksionojë). E rëndësishme është që certifikata e re përmban të njëjtin emër subjekti dhe të njëjtin çelës publik si certifikata e vjetër, ndaj nënshkrimi i saj në certifikatën përfundimtare do të jetë i vlefshëm. Firefox është mjaftueshëm i zgjuar sa të provojë të dyja mundësitë derisa të gjejë atë që funksionon, prandaj shtesat do të verifikohen sërish. Vini re se kjo është e njëjta logjikë që përdorim për verifikimin e certifikatave TLS.
Shënim i autorit: lexuesit që njohin WebPKI do të vënë re se certifikatat e kryqëzuara funksionojnë pikërisht në të njëjtën mënyrë.
Pjesa më e mirë e këtij rregullimi është se nuk kërkon rinënshkrimin e shtesave ekzistuese. Sapo shfletuesi të marrë certifikatën e re, të gjitha shtesat do të fillojnë të funksionojnë sërish. Sfida që mbetet është dorëzimi i certifikatës së re te përdoruesit (automatikisht dhe nga distanca), si edhe detyrimi i Firefox që të riverifikojë shtesat e çaktivizuara.
Normandy dhe sistemi i studimeve
Ironikisht, kjo problematikë zgjidhet nga një shtesë e posaçme e quajtur “sistemore”. Për të kryer studime, ne kemi zhvilluar një sistem të quajtur Normandy, i cili ua shpërndan studimet përdoruesve. Këto studime ekzekutohen automatikisht në shfletues dhe kanë qasje të zgjeruar në API-të e brendshme të Firefox. Studimet mund të shtojnë certifikata të reja në depozitën e certifikatave.
Shënim i autorit: ne nuk po shtojmë një certifikatë me ndonjë privilegj të veçantë; ajo është nënshkruar nga certifikata rrënjë, prandaj Firefox i beson. Ne thjesht po e shtojmë atë në grupin e certifikatave që mund të përdoren nga shfletuesi.
Kështu, zgjidhja është të krijohet një studim:
- që u instalon përdoruesve certifikatën e re që kemi krijuar
- që e detyron shfletuesin të riverifikojë shtesat e çaktivizuara, në mënyrë që të funksionojnë sërish
“Por prit”, do të thoni ju, “shtesat nuk funksionojnë, si mund të niset një shtesë sistemore?”. Do ta nënshkruajmë me certifikatën e re!
Le t’i bashkojmë të gjitha… pse po zgjat kaq shumë?
Pra, plani ishte ky: të lëshonim një certifikatë të re për të zëvendësuar të vjetrën, të krijonim një shtesë sistemi dhe t’ua instalonim përdoruesve përmes Normandy. Problemet, siç e përmenda, nisën më 4 maj në orën 4:00, ndërsa në 12:44 të po asaj dite, pra në më pak se 9 orë, ne dërguam rregullimin në Normandy. U deshën edhe 6-12 orë të tjera që ai të arrinte te të gjithë përdoruesit. Kjo tashmë është mjaft mirë, por përdoruesit në Twitter pyesin pse nuk mund të vepronim më shpejt.
Së pari, duhej kohë për të lëshuar një certifikatë të re ndërmjetëse. Siç e përmenda më sipër, çelësi i certifikatës rrënjë ruhet offline në një modul harduerik sigurie. Kjo është e mirë nga pikëpamja e sigurisë, sepse certifikata rrënjë përdoret shumë rrallë dhe duhet të mbrohet në mënyrë të besueshme, por është disi e papërshtatshme kur duhet të nënshkruhet urgjentisht një certifikatë e re. Njërit prej inxhinierëve tanë iu desh të shkonte në vendin ku ruhej HSM. Më pas pati përpjekje të pasuksesshme për të lëshuar certifikatën e duhur dhe secila përpjekje kushtonte një deri në dy orë të shpenzuara për testim.
Së dyti, zhvillimi i shtesës së sistemit mori gjithashtu pak kohë. Në aspektin konceptual kjo është shumë e thjeshtë, por edhe programet e thjeshta kërkojnë kujdes. Ne donim të siguroheshim që të mos e përkeqësonim edhe më shumë situatën. Zgjidhja duhej testuar përpara se t’u dërgohej përdoruesve. Për më tepër, shtesa duhej të nënshkruhej, por sistemi ynë i nënshkrimit të shtesave ishte çaktivizuar, ndaj u desh të gjendej një rrugë alternative.
Së fundi, pasi i përgatitëm studimet për dërgim, u desh edhe kohë për shpërndarjen. Shfletuesi kontrollon për përditësime të Normandy çdo 6 orë. Jo të gjithë kompjuterët janë vazhdimisht të ndezur dhe të lidhur me internetin, prandaj duhet kohë që rregullimi të shpërndahet te përdoruesit.
Hapat përfundimtarë
Studimi duhet ta zgjidhë problemin për shumicën e përdoruesve, por nuk është i disponueshëm për të gjithë. Për disa përdorues nevojitet një qasje e veçantë:
- përdoruesit që kanë çaktivizuar studimet ose telemetrinë
- përdoruesit e versionit Android (Fennec), ku studimet nuk mbështeten fare
- përdoruesit e versioneve të personalizuara të Firefox ESR në mjedise biznesi, ku nuk është e mundur të aktivizohet telemetria
- Përdoruesit që kalojnë përmes një proxy MitM, pasi sistemi ynë i instalimit të shtesave përdor key pinning, i cili nuk funksionon me proxy të tillë
- Përdoruesit e versioneve të vjetruara të Firefox që nuk mbështesin studies
Për kategorinë e fundit të përdoruesve nuk mund të bëjmë asgjë — ata gjithsesi duhet të përditësojnë në një version të ri të Firefox, sepse versionet e vjetra kanë dobësi serioze të pazgjidhura. E dimë që disa përdorues qëndrojnë te versionet e vjetra të Firefox sepse duan të përdorin shtesa të vjetra, por shumë prej tyre tashmë janë përshtatur për versionet e reja të shfletuesit. Për përdoruesit e tjerë kemi zhvilluar një patch që do të instalojë një certifikatë të re. Ai u publikua si një bugfix release (Shënim i përkthyesit: Firefox 66.0.5), ndaj përdoruesit do ta marrin — dhe me shumë gjasa e kanë marrë tashmë — përmes kanalit të zakonshëm të përditësimit. Nëse përdorni një build të personalizuar të Firefox ESR, kontaktoni mirëmbajtësin tuaj.
E kuptojmë që e gjithë kjo nuk është ideale. Në disa raste, përdoruesit humbën të dhënat e shtesave (për shembull, të dhënat e shtesës Multi-Account Containers).
Ky efekt anësor nuk mund të shmangej, por besojmë se në afat të shkurtër kemi zgjedhur zgjidhjen më të mirë për shumicën e përdoruesve. Në afat të gjatë do të kërkojmë qasje të tjera arkitekturore, më të avancuara.
Mësimet
Së pari, ekipi ynë bëri një punë të jashtëzakonshme duke krijuar dhe dërguar rregullimin në më pak se 12 orë pas zbulimit të problemit. Si dikush që ishte i pranishëm në mbledhje, mund të them se në këtë situatë të vështirë njerëzit punuan shumë fort dhe u humb shumë pak kohë kot.
Është e qartë se asgjë nga kjo nuk duhej të kishte ndodhur fare. Proceset tona duhen përmirësuar që të ulim gjasat e incidenteve të tilla dhe ta bëjmë më të lehtë korrigjimin e pasojave.
Javën e ardhshme do të publikojmë një post-mortem zyrtar dhe një listë ndryshimesh që synojmë të bëjmë. Për momentin, dua të ndaj disa mendime të miat. Së pari, duhet të kemi një mënyrë më të mirë për të monitoruar gjendjen e asaj që mund të kthehet në një bombë me sahat. Duhet të sigurohemi që të mos përfundojmë në një situatë ku njëra prej tyre aktivizohet papritur. Ende po punojmë mbi detajet, por, të paktën, duhet të bëjmë një inventar të plotë të të gjitha rasteve të tilla.
Së dyti, na duhet një mekanizëm për dërgimin e shpejtë të përditësimeve te përdoruesit, edhe kur — veçanërisht kur — gjithçka tjetër nuk funksionon. Ishte mirë që arritëm të përdornim sistemin e “studimeve”, por ai nuk është një mjet i përsosur dhe sjell disa efekte anësore të padëshiruara. Në veçanti, e dimë që shumë përdorues i kanë të aktivizuara përditësimet automatike, por do të preferonin të mos merrnin pjesë në studime (e pranoj, edhe unë i kam të çaktivizuara!). Në të njëjtën kohë, na duhet një mënyrë për t’u dërguar përdoruesve përditësime, por, pavarësisht nga zbatimi i brendshëm teknik, përdoruesit duhet të kenë mundësi të abonohen për përditësime (përfshirë rregullimet urgjente), por të heqin dorë nga gjithçka tjetër. Për më tepër, kanali i përditësimeve duhet të jetë më i shpejtë në reagim se sa është tani. Edhe më 6 maj kishte ende përdorues që nuk kishin marrë as rregullimin dhe as versionin e ri. Punohej tashmë mbi këtë problem, por ajo që ndodhi tregoi sa i rëndësishëm është ai.
Së fundi, do të shqyrtojmë arkitekturën e sigurisë së shtesave për t’u siguruar që ajo ofron nivelin e duhur të mbrojtjes me rrezikun minimal për të prishur diçka.
Javën e ardhshme do të shqyrtojmë rezultatet e një analize më të thelluar të asaj që ndodhi, ndërsa ndërkohë do të jem i lumtur t’u përgjigjem pyetjeve me email: ekr-blog@mozilla.com
Burimi: linux.org.ru
