Shënim përkthyes: për lehtësi të lexuesve, datat janë paraqitur sipas kohës së Moskës
Sapo ne humbëm momentin e skadimit të një nga certifikatave të përdorura për nënshkrimin e shtesave. Kjo çoi në ndalimin e shtesave për përdoruesit. Tani, pasi problemi është kryesisht zgjidhur, doja të flas për detajet e ngjarjes dhe punën e bërë.
Arsyeja: shtesat dhe nënshkrimet
Shtesat e instaluara duhet të kenë nënshkrimin digjital, i cili mbron përdoruesit nga shtesat e dëmshme, dhe kërkon një verifikim minim të shtesave nga punonjësit e Mozilla. Ne e vendosëm këtë kërkesë në vitin 2015, pasi përjetuam probleme serioze me shtesat e dëmshme.
Si si funksionon: çdo kopje e Firefox përmban "çertifikatën rrënjësore". Çelësi i këtij "rrënje" ruhet në modulin e mbrojtjesHarduerike (HSM), pa akses në rrjet. Çdo disa vjet, ky çelës përdoret për të nënshkruar një "çertifikatë të re ndërmjetëse", e cila përdoret për nënshkrimin e shtesave. Kur një zhvillues dërgon një shtesë, ne krijojmë një "çertifikatë përfundimtare" të përkohshme dhe e nënshkruajmë atë duke përdorur çertifikatën ndërmjetëse. Pastaj, çertifikata përfundimtare nënshkruan vetë shtesën. Schematically këtu duket kështu.
Kujdes: çdo çertifikatë ka një "subjekt" (këndej i është dhënë çertifikata) dhe një "botues" (kush e dha çertifikatën). Në rastin e çertifikatës rrënjësore, "subjekti" = "botuesi", por për çertifikatat e tjera, botuesi i çertifikatës është subjekti i çertifikatës më të lartë, i cili e ka nënshkruar atë.
Një pikë e rëndësishme: çdo shtesë është nënshkruar me një çertifikatë unike përfundimtare, por pothuajse gjithmonë këto çertifikata përfundimtare janë nënshkruar nga e njëjta çertifikatë ndërmjetëse.
Shënim i autorit: përjashtim — shtesat shumë të vjetra. Në atë kohë u përdorën certifikata të ndryshme ndërmjetëse.
Kjo certifikatë ndërmjetëse shkaktoi probleme: çdo certifikatë është e vlefshme për një periudhë të caktuar. Para ose pas kësaj periudhe, certifikata nuk është e vlefshme, dhe shfletuesi nuk do të përdorë shtesat e nënshkruara nga kjo certifikatë. Fatkeqësisht, afati i skadencës së certifikatës ndërmjetëse skadoi më 4 maj në orën 4 të mëngjesit.
Pasojat nuk u shfaqën menjëherë. Firefox kontrollon nënshkrimet e shtesave të instaluara jo vazhdimisht, por rreth çdo 24 orë, dhe koha e kontrollit është individuale për çdo përdorues. Si rezultat, disa njerëz përballeshin me probleme menjëherë, ndërsa disa shumë më vonë. Ne e mësuam për herë të parë mbi problemin rreth atij momenti, kur afati i certifikatës skadoi, dhe menjëherë filluam të kërkojmë një zgjidhje.
Minimizojmë dëmin
Sa herë që kuptuam se çfarë ndodhi, përpiqeshim të parandalojmë përkeqësimin e situatës.
Së pari, ndaluam pranimin dhe nënshkrimin e plotësimeve të reja. Nuk ka kuptim të përdorim një certifikatë të skaduar për këtë. Duke shikuar pas, do të thosha se do të ishte mirë të kishim lënë gjithçka ashtu siç ishte. Tani pranimi i plotësimeve është rinisur.
Së dyti, dërguam menjëherë një korrigjim që parandaloi kontrollin e nënshkrimeve çdo ditë. Në këtë mënyrë, shpëtuam ata përdorues të cilëve shfletuesi nuk kishte pasur kohë ta kontrollonte plotësimin gjatë 24 orëve të fundit. Tani ky korrigjim është tërhequr, nuk ka më nevojë për të.
Puna paralele
Teorikisht, zgjidhja e problemit duket e thjeshtë: krijojmë një certifikatë intermediare të re dhe nënshkruajmë përsëri secilin plotësim. Fatkeqësisht, kjo nuk do të funksionojë:
- ne nuk mund ta nënshkruajmë shpejt 15,000 plotësime njëherësh, sistemi nuk është i ndërtuar për një ngarkesë të tillë.
- mbasë që të nënshkruajmë shtesat, versionet e përditësuara duhet dorëzuar përdoruesve. Shumica e shtesave instalohen nga serverët e Mozilla, prandaj brenda 24 orëve të ardhshme Firefox do të gjejë përditësime, por disa zhvillues shpërndajnë shtesa të nënshkruara përmes kanaleve të tjera, kështu që përdoruesit do të duhet t'i përditësojnë ato manualisht.
Në vend të kësaj, ne përpiqemi të zhvillojmë një korrigjim që do të arrijë të gjithë përdoruesit, duke mos kërkuar (ose pothuajse pa kërkuar) veprime nga ana e tyre.
Shpejt arritëm në dy strategji kryesore, të cilat i përdorëm paralelisht:
- Përditëso Firefox-in për të ndryshuar periudhën e vlefshmërisë së certifikatës. Kjo do të bëjë që shtesat ekzistuese të funksionojnë përsëri, por do të kërkonte lëshimin dhe dorëzimin e një ndërtese të re të Firefox.
- Të krijojmë një certifikatë të vlefshme dhe si ndonjëfarë mënyre t'i bindim Firefox-it ta pranojë atë në vend të ekzistueses, e cila është skaduar.
Ne vendosëm të përdorim më parë opsionin e parë, i cili dukej mjaft i zbatueshëm. Në fund të ditës lëshuam dhe një korrigjim të dytë (certifikatën e re), për të cilën do të flasim më vonë.
Zëvendësimi i certifikatës
Siç e përmenda më sipër, kërkohej:
- të krijohet një certifikatë e re dhe valide
- ta instaloni atë nga distanca në Firefox
Për të kuptuar pse kjo do të funksionojë, le të shqyrtojmë më në detaje procesin e verifikimit të shtesës. Vetë shtesa vjen në formën e një grumbulli skedarësh, duke 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ësore, e cila integrohet në Firefox gjatë ndërtimit. Megjithatë, siç e dimë tashmë, certifikata ndërmjësuese ka skaduar, kështu që nuk është e mundur të verifikohet shtesa.
Kur Firefox provon të verifikojë një shtesë, ai nuk kufizohet në përdorimin e certifikatave që përmban vetë shtesa. Në vend të kësaj, shfletuesi përpiqet të krijojë një zinxhir të vlefshëm certifikatash, duke filluar nga certifikata përfundimtare dhe vazhdon deri në rrënjën. Në nivelin e parë, fillojmë me certifikatën përfundimtare, dhe pastaj gjejmë certifikatën, subjekti i së cilës është botuesi i certifikatës përfundimtare (dmth, certifikata ndërmjetëse). Zakonisht, kjo certifikatë ndërmjetëse jepet me shtesën, por gjithashtu mund të shërbejë çdo certifikatë nga depoja e shfletuesit. Nëse arrijmë të shtojmë në mënyrë të largët një certifikatë të re të vlefshme në depozitat e certifikatave, 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 opsione kur kontrollon zinxhirin e certifikatave: të përdorë certifikatën e vjetër të pavlefshme (e cila nuk do të funksionojë) ose certifikatën e re të vlefshme (e cila do të funksionojë). Është e rëndësishme që certifikata e re ka të njëjtin emër subjekti dhe çelës publik si certifikata e vjetër, kështu që nënshkrimi i saj në certifikatën përfundimtare do të jetë i vlefshëm. Firefox është mjaft i zgjuar për të provuar të dy opsionet derisa të gjejë atë që punon, kështu që shtesat do të verifikohen përsëri. Vini re, kjo është e njëjta logjikë që ne përdorim për verifikimin e certifikatave TLS.
Shënimi i autorit: lexuesit që janë të njohur me WebPKI do të vërejnë se certifikatat ndërkryesore funksionojnë në të njëjtën mënyrë.
Ajo që është më e mrekullueshme në këtë rregullim është se nuk kërkon ri-nënshkrimin e shtesave ekzistuese. Sa herë që shfletuesi merr certifikatën e re, të gjitha shtesat do të funksionojnë përsëri. Ngelet një vështirësi me dërgimin e certifikatës së re te përdoruesit (në mënyrë automatike dhe nga distanca), si dhe të bëjmë që Firefox të rishikojë shtesat e çaktivizuara.
Normandy dhe sistemi i kërkimeve
Me çudir, kjo problem zgjidhet nga një shtesë e veçantë e quajtur "sistemi". Për të kryer hulumtime, ne zhvilluam një sistem të quajtur Normandy, i cili bën të mundur dërgimin e hulumtimeve te përdoruesit. Këto hulumtime kryhen automatikisht në shfletues dhe kanë qasje të zgjeruar në API-të e brendshme të Firefox. Hulumtimet mund të shtojnë certifikata të reja në magazinën e certifikatave.
Vërejtje e autorit: ne nuk e shtojmë certifikatën me ndonjë privilegj të veçantë; ajo është nënshkruar nga një certifikatë rrënjësore, prandaj Firefox-i i beson. Ne thjesht e shtojmë atë në grupin e certifikatave që mund të përdoren nga shfletuesi.
Pra, zgjidhja është të krijohet një hulumtim:
- që vendos certifikatën e re të krijuar nga ne për përdoruesit
- duke i detyruar shfletuesit të rishikojnë shtesat e çaktivizuara për t'i bërë ato të funksionojnë përsëri
"Por prit", do të thoni ju, "shtesat nuk funksionojnë, si ta aktivizojmë një shtesë sistemi?". Ta nënshkruajmë me certifikatën tonë të re!
Të gjithë së bashku... përse ndodhi këtë kaq gjatë?
Pra, plani është: të lëshohet një certifikatë e re për të zëvendësuar atë të vjetër, të krijohet një shtesë sistemore dhe të instalohet për përdoruesit përmes Normandy. Problemet, siç e kam thënë, filluan më 4 maj në orën 4:00, dhe më 12:44 të të njëjtit ditë, pak më pak se 9 orë më vonë, ne dërguam një rregullim në Normandy. Nevojiteshin edhe 6-12 orë që të arrinte te të gjithë përdoruesit. Mjaft mirë, por përdoruesit në Twitter po pyesin pse nuk mund të vepronim më shpejt.
Së pari, duhet kohë për të lëshuar një certifikatë të re ndërmjetëse. Siç e përmenda më lart, çelësi i certifikatës rrënjës ruhet në mënyrë autonome në një modul sigurie harduari. Kjo është e mirë nga pika epamjes së sigurisë, pasi rrënja përdoret shumë rrallë dhe duhet të jetë e mbrojtur fort, por është pak e shqetësueshme kur duhet të firmoset urgjentisht një certifikatë e re. Një nga inxhinierët tanë duhet të shkonte në depo HSM. Më pas pati përpjekje të pasuksesshme për të lëshuar certifikatën e duhur, dhe çdo përpjekje merrte një ose dy orë për t'u testuar.
Së pari, zhvillimi i shtesës sistemore mori pak kohë. Konceptualisht, është shumë e thjeshtë, por edhe programet e thjeshta kërkojnë kujdes. Donim të siguroheshim që situata të mos bëhej edhe më keq. Kërkimi duhet të testohet para se të dërgohet te përdoruesit. Përveç kësaj, shtesa duhet të jetë e nënshkruar, por sistemi ynë për nënshkrimin e shtesave ishte çaktivizuar, kështu që duhej të kërkonim një zgjidhje alternative.
Më në fund, pasi e përgatitëm kërkimin për dërgim, mori kohë për implementimin. Shfletuesi kontrollon për azhurnime Normandy çdo 6 orë. Jo të gjitha kompjuterët janë vazhdimisht të ndezur dhe të lidhur me internet, prandaj kërkohet kohë për korrigjimin të shpërndahet te përdoruesit.
Hapat përfundimtarë
Kërkimi duhet të zgjidhë problemin për shumicën e përdoruesve, por nuk është i disponueshëm për të gjithë. Disa përdorues kërkojnë një qasje të veçantë:
- përdoruesit që kanë çaktivizuar kërkimin ose telemetrinë
- përdoruesit e versionit Android (Fennec), ku kërkimi nuk mbështetet aspak
- përdoruesit e ndërtimeve të personalizuara të Firefox ESR në ndërmarrje, ku nuk është e mundur të aktivizohet telemetria
- përdoruesit që janë prapa proxy MitM, pasi sistemi ynë i instalimit të shtesave përdor lidhjen e çelësave (key pinning), e cila nuk funksionon me këto proxy
- përdoruesit e versioneve të vjetra të Firefox-it, që nuk mbështesin hulumtimet
Nuk mund të bëjmë asgjë për kategorinë e fundit të përdoruesve — ata duhet të azhurnojnë në versionin më të ri të Firefox-it, sepse versionet e vjetra kanë disa vulnerabilitete serioze të pa adresuara. E dimë se disa njerëz qëndrojnë në versionet e vjetra të Firefox-it për të përdorur shtesa të vjetra, por shumë nga shtesat e vjetra tashmë janë portuar në versionet e reja të shfletuesit. Për përdoruesit e tjerë kemi zhvilluar një patch, që do të instalojë certifikatën e re. Ai u lëshua si një version për riparimin e gabimeve (shënim i përkthyesit: Firefox 66.0.5), kështu që njerëzit do ta marrin atë — shumë mundësi e kanë marrë tashmë — përmes kanalit të zakonshëm të azhurnimit. Nëse jeni duke përdorur një ndërtim të personalizuar të Firefox ESR, kontaktoni mbajtësin tuaj.
E kuptojmë se gjithçka nuk është perfekte. Në disa raste, përdoruesit humbën të dhënat e shtesave (p.sh., të dhënat e shtesës Multi-Account Containers).
Ky këtij efekti anësor nuk mund t'i iknim, por mendojmë se për shumicën e përdoruesve zgjodhëm zgjidhjen më të mirë në afat të shkurtër. Në afat të gjatë, do të kërkojmë qasje më të sofistikuara arkitektonike.
Mësimet
Së pari, ekipi ynë ka bërë një punë të mrekullueshme duke krijuar dhe dërguar një rregullim për më pak se 12 orë pas zb discovery të problemit. Si një person që ka qenë prezent në takime, mund të them se në këtë situatë të vështirë njerëzit punuan shumë dhe u humb pak kohë.
Është e qartë se asgjë nga gjithë kjo nuk duhej të ndodhte. Me siguri duhet të rregullojmë proceset tona për të ulur mundësinë e incidenteve të ngjashme dhe për të lehtësuar rregullimin e pasojave.
Në javën e ardhshme do të publikojmë një post-mortem zyrtar dhe një listë të ndryshimeve që kemi për qëllim të bëjmë. Deri atëherë, do të ndaj mendimet e mia. Në radhë të parë, duhet të ketë një mënyrë më të mirë për të ndjekur gjendjen e asaj që është një potencial bombë me vonesë. Duhet të jemi të sigurt se nuk do të përfundojmë në një situatë ku ndonjëra prej tyre shpërthen papritur. Ndërsa akoma po punojmë në detaje, të paktën duhet të bëjmë një inventar të të gjitha këtyre gjërave.
Së pari, na nevojitet një mekanizëm për dërgimin e shpejtë të azhurnimeve te përdoruesit, madje edhe kur—veçanërisht kur—gjithçka tjetër nuk funksionon. Ishte e shkëlqyer që mundëm të përdorim sistemin e "kërkimeve", por ky është një mjet i paperfekt dhe ka disa efekte anësore të padëshiruara. Në veçanti, dimë që shumë përdorues kanë aktivizuar azhurnimin automatik, por do të preferonin të mos merrnin pjesë në kërkime (po e pranoj, edhe unë i kam ato të çaktivizuara!). Në të njëjtën kohë, na nevojitet një mënyrë për t'u dërguar azhurnime përdoruesve, por, pavarësisht se cila do të ishte realizimi teknik brenda, përdoruesit duhet të kenë mundësinë të bëjnë subscribe për azhurnimet (përfshirë rregullime emergjente), duke u hequr dorë nga gjithçka tjetër. Gjithashtu, kanali i azhurnimeve duhet të jetë më reagues se tani. Edhe më 6 maj kishte përdorues që nuk e kishin shfrytëzuar asnjë rregullim, as versionin e ri. Kemi punuar mbi këtë problem, por ajo që ndodhi tregoi sa e rëndësishme është.
Më në fund, ne do të shqyrtojmë arkitekturën e sigurisë së shtesave, për të siguruar që ajo ofron nivelin e duhur të sigurisë me rrezik minimal për të prishur diçka.
Java e ardhshme ne do të shqyrtojmë rezultatet e një analize më të hollësishme të asaj që ndodhi, ndërkohë që do të isha i lumtur të përgjigjem në pyetje përmes email-it: ekr-blog@mozilla.com
Burimi: linux.org.ru
