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
