shënim përkthyesi: për lehtësinë e lexuesve, datat jepen në kohën e Moskës
Kohët e fundit kemi humbur skadimin e një prej certifikatave të përdorura për të nënshkruar shtesat. Kjo rezultoi në çaktivizimin e shtesave për përdoruesit. Tani që problemi është rregulluar kryesisht, do të doja të ndaja detajet e asaj që ndodhi dhe punës që u bë.
Sfondi: shtesa dhe nënshkrime
Shtesat e instaluara duhet të kenë nënshkrim dixhital, i cili mbron përdoruesit nga shtesat me qëllim të keq dhe kërkon shqyrtim minimal të shtesave nga stafi i Mozilla-s. Ne e kemi paraqitur këtë kërkesë në vitin 2015 sepse po e përjetonim probleme serioze me shtesa me qëllim të keq.
Si funksionon: Çdo kopje e Firefox-it përmban një "çertifikatë rrënjësore". Çelësi i kësaj "rrënjë" ruhet në Moduli i Sigurisë së Hardware (HSM)pa akses në rrjet. Çdo disa vjet, një "çertifikatë e ndërmjetme" e re nënshkruhet me këtë çelës, i cili përdoret gjatë nënshkrimit të shtesave. Kur një zhvillues paraqet një shtesë, ne krijojmë një "çertifikatë përfundimi" të përkohshme dhe e nënshkruajmë atë duke përdorur një certifikatë të ndërmjetme. Vetë shtesa më pas nënshkruhet me certifikatën përfundimtare. Skematikisht duket kështu.
Ju lutemi vini re se çdo certifikatë ka një "subjekt" (të cilit i është lëshuar certifikata) dhe një "lëshues" (i cili ka lëshuar certifikatën). Në rastin e një certifikate rrënjë, "subject" = "lëshues", por për certifikatat e tjera, lëshuesi i certifikatës është subjekt i certifikatës mëmë me të cilën është nënshkruar.
Një pikë e rëndësishme: çdo shtesë nënshkruhet nga një certifikatë përfundimtare unike, por pothuajse gjithmonë këto certifikata fundore nënshkruhen nga e njëjta certifikatë e ndërmjetme.
Shënim i autorit: Përjashtim bëjnë shtesat shumë të vjetra. Në atë kohë përdoreshin certifikata të ndryshme të ndërmjetme.
Kjo certifikatë e ndërmjetme shkaktoi probleme: çdo certifikatë është e vlefshme për një periudhë të caktuar. Para ose pas kësaj periudhe, certifikata është e pavlefshme dhe shfletuesi nuk do të përdorë shtesa të nënshkruara nga kjo certifikatë. Fatkeqësisht, certifikata e ndërmjetme skadoi më 4 maj në orën 4 të mëngjesit.
Pasojat nuk u shfaqën menjëherë. Firefox-i nuk kontrollon vazhdimisht nënshkrimet e shtesave të instaluara, por afërsisht një herë në 24 orë, dhe koha e verifikimit është individuale për çdo përdorues. Si rezultat, disa njerëz përjetuan probleme menjëherë, ndërsa të tjerët përjetuan probleme shumë më vonë. Fillimisht u bëmë të vetëdijshëm për problemin në kohën kur certifikata skadoi dhe filluam menjëherë të kërkonim një zgjidhje.
Reduktimi i dëmeve
Pasi kuptuam se çfarë kishte ndodhur, u përpoqëm të parandalonim që situata të përkeqësohej.
Së pari, ata ndaluan pranimin dhe nënshkrimin e shtesave të reja. Nuk ka kuptim të përdorni një certifikatë të skaduar për këtë. Duke parë prapa, do të thosha se mund të kishim lënë gjithçka ashtu siç ishte. Tani kemi rifilluar pranimin e suplementeve.
Së dyti, ata dërguan menjëherë një rregullim që pengonte nënshkrimet të kontrolloheshin çdo ditë. Kështu, ne shpëtuam ata përdorues, shfletuesi i të cilëve nuk kishte ende kohë për të kontrolluar shtesat në 24 orët e fundit. Ky rregullim tani është tërhequr dhe nuk është më i nevojshëm.
Operacioni paralel
Në teori, zgjidhja e problemit duket e thjeshtë: krijoni një certifikatë të re të vlefshme ndërmjetëse dhe ri-nënshkruani çdo shtesë. Fatkeqësisht kjo nuk do të funksionojë:
- ne nuk mund të ri-nënshkruash shpejt 15 mijë shtesa menjëherë, sistemi nuk është krijuar për një ngarkesë të tillë
- Pasi të nënshkruajmë shtesat, versionet e përditësuara duhet t'u dorëzohen përdoruesve. Shumica e shtesave janë instaluar nga serverët e Mozilla-s, kështu që Firefox-i do të gjejë përditësime brenda 24 orëve të ardhshme, por disa zhvillues shpërndajnë shtesa të nënshkruara përmes kanaleve të palëve të treta, kështu që përdoruesit duhet t'i përditësojnë këto shtesa manualisht
Në vend të kësaj, ne u përpoqëm të zhvillonim një rregullim që do të arrinte të gjithë përdoruesit pa kërkuar shumë ose aspak veprime nga ana e tyre.
Shumë shpejt arritëm te dy strategji kryesore, të cilat i përdorëm paralelisht:
- Përditësoni 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 në mënyrë magjike, por do të kërkojë lëshimin dhe dërgimin e një ndërtese të re të Firefox-it
- Gjeneroni një certifikatë të vlefshme dhe bindni disi Firefox-in ta pranojë atë në vend të asaj ekzistuese që ka skaduar
Vendosëm të përdorim fillimisht opsionin e parë, i cili dukej mjaft i zbatueshëm. Në fund të ditës, ata lëshuan një rregullim të dytë (një certifikatë të re), për të cilën do të flasim më vonë.
Zëvendësimi i një certifikate
Siç e përmenda më lart, kërkohej:
- krijoni një certifikatë të re të vlefshme
- instaloni atë nga distanca në Firefox
Për të kuptuar pse funksionon kjo, le të hedhim një vështrim më të afërt në procesin e verifikimit të shtesës. Vetë shtesa vjen si një grup skedarësh, duke përfshirë një zinxhir certifikatash të përdorura për nënshkrim. Si rezultat, shtesa mund të verifikohet nëse shfletuesi e njeh certifikatën rrënjë, e cila është e integruar në Firefox në kohën e ndërtimit. Megjithatë, siç e dimë tashmë, certifikata e ndërmjetme ka skaduar, kështu që është e pamundur të verifikohet shtesa.
Kur Firefox-i përpiqet të verifikojë një shtesë, ajo nuk kufizohet në përdorimin e certifikatave që gjenden brenda vetë shtesës. Në vend të kësaj, shfletuesi përpiqet të krijojë një zinxhir të vlefshëm certifikate, duke filluar me certifikatën përfundimtare dhe duke vazhduar derisa të arrijë në rrënjë. Në nivelin e parë, fillojmë me certifikatën e përfundimit dhe më pas gjejmë certifikatën, subjekti i së cilës është lëshuesi i certifikatës së përfundimit (domethënë certifikata e ndërmjetme). Zakonisht kjo certifikatë e ndërmjetme jepet me shtesën, por çdo certifikatë nga ruajtja e shfletuesit mund të shërbejë gjithashtu si certifikatë e ndërmjetme. Nëse mund të shtojmë nga distanca një certifikatë të re të vlefshme në dyqanin e certifikatave, Firefox do të përpiqet ta përdorë atë. Situata para dhe pas instalimit të një certifikate të re.
Pas instalimit të certifikatës së re, Firefox-i do të ketë dy opsione kur vërteton 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 të përmbajë 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-i është mjaft i zgjuar për të provuar të dyja opsionet derisa të gjejë një që funksionon, kështu që shtesat testohen përsëri. Vini re se kjo është e njëjta logjikë që përdorim për të vërtetuar certifikatat TLS.
Shënim i autorit: Lexuesit e njohur me WebPKI do të vërejnë se certifikatat e kryqëzuara funksionojnë saktësisht në të njëjtën mënyrë.
Gjëja më e mirë për këtë rregullim është se nuk kërkon që ju të ri-nënshkruani shtesat ekzistuese. Sapo shfletuesi të marrë certifikatën e re, të gjitha shtesat do të funksionojnë përsëri. Sfida e mbetur është dërgimi i certifikatës së re te përdoruesit (automatikisht dhe nga distanca), si dhe marrja e Firefox-it për të ri-kontrolluar shtesat e çaktivizuara.
Normandia dhe sistemi i kërkimit
Ironikisht, ky problem zgjidhet nga një shtesë e veçantë e quajtur "sistemi". Për të kryer kërkime, ne zhvilluam një sistem të quajtur Normandi që u ofron kërkime përdoruesve. Këto studime kryhen automatikisht në shfletues dhe kanë akses të përmirësuar në API-të e brendshme të Firefox-it. Hulumtimi mund të shtojë certifikata të reja në dyqanin e certifikatave.
Shënim i autorit: Ne nuk po shtojmë një certifikatë me ndonjë privilegj të veçantë; ajo është e nënshkruar nga certifikata rrënjë, kështu që Firefox-i i beson. Ne thjesht e shtojmë atë në grupin e certifikatave që mund të përdoren nga shfletuesi.
Pra, zgjidhja është krijimi i një studimi:
- instalimi i certifikatës së re që krijuam për përdoruesit
- duke e detyruar shfletuesin të kontrollojë përsëri shtesat e çaktivizuara në mënyrë që ato të funksionojnë përsëri
"Por prisni," thoni ju, "shtesat nuk funksionojnë, si mund të hap një shtesë sistemi?" Le ta nënshkruajmë me një certifikatë të re!
Duke i bashkuar të gjitha... pse po zgjat kaq shumë?
Pra, plani: lëshoni një certifikatë të re për të zëvendësuar të vjetrën, krijoni një shtesë sistemi dhe instaloni atë te përdoruesit nëpërmjet Normandisë. Problemet, siç thashë, filluan më 4 maj në orën 4:00 dhe tashmë në orën 12:44 të së njëjtës ditë, më pak se 9 orë më vonë, dërguam një rregullim në Normandi. U deshën 6-12 orë të tjera që ai të arrinte të gjithë përdoruesit. Nuk është aspak keq, por njerëzit në Twitter po pyesin pse nuk mund të kishim vepruar më shpejt.
Së pari, u desh kohë për të lëshuar një certifikatë të re të ndërmjetme. Siç e përmenda më lart, çelësi i certifikatës rrënjësore ruhet jashtë linje në modulin e sigurisë së harduerit. Kjo është e mirë nga pikëpamja e sigurisë, pasi rrënja përdoret shumë rrallë dhe duhet të mbrohet me besueshmëri, por është paksa e papërshtatshme kur duhet të nënshkruani urgjentisht një certifikatë të re. Një nga inxhinierët tanë duhej të udhëtonte në objektin e magazinimit HSM. Më pas pati përpjekje të pasuksesshme për të lëshuar certifikatën e saktë dhe secila përpjekje kushtoi një ose dy orë testim.
Së dyti, zhvillimi i shtesës së sistemit mori pak kohë. Konceptualisht është shumë e thjeshtë, por edhe programet e thjeshta kërkojnë kujdes. Ne donim të siguroheshim që të mos e përkeqësonim situatën. Hulumtimi duhet të testohet përpara se t'u dërgohet përdoruesve. Përveç kësaj, shtesa duhet të nënshkruhet, por sistemi ynë i nënshkrimit të shtesës ishte çaktivizuar, kështu që na u desh të gjenim një zgjidhje.
Më në fund, sapo të kishim kërkimin gati për dorëzim, vendosja mori kohë. Shfletuesi kontrollon për përditësime të Normandisë çdo 6 orë. Jo të gjithë kompjuterët janë gjithmonë të ndezur dhe të lidhur me internetin, kështu që do të duhet kohë që rregullimi të përhapet te përdoruesit.
Hapat e fundit
Hulumtimi duhet të rregullojë 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 fare
- përdoruesit e ndërtimeve të personalizuara të Firefox ESR në ndërmarrjet ku telemetria nuk mund të aktivizohet
- përdoruesit që ulen pas proxies MitM, pasi sistemi ynë i instalimit të shtesave përdor fiksimin e çelësit, i cili nuk funksionon me përfaqësues të tillë
- përdoruesit e versioneve të vjetra të Firefox-it që nuk mbështesin kërkimin
Ne nuk mund të bëjmë asgjë për kategorinë e fundit të përdoruesve - ata duhet të përditësohen në versionin e ri të Firefox-it, sepse ato të vjetruara kanë dobësi serioze të papatched. Ne e dimë se disa njerëz qëndrojnë në versionet më të vjetra të Firefox-it sepse duan të ekzekutojnë shtesa të vjetra, por shumë nga shtesat e vjetra janë transferuar tashmë në versionet më të reja të shfletuesit. Për përdoruesit e tjerë, ne kemi zhvilluar një patch që do të instalojë një certifikatë të re. Ai u lëshua si një version i rregullimit të gabimeve (shënimi i përkthyesit: Firefox 66.0.5), kështu që njerëzit do ta marrin atë - me shumë mundësi e kanë marrë tashmë - përmes kanalit të përditësimit të rregullt. Nëse jeni duke përdorur një ndërtim të personalizuar të Firefox ESR, ju lutemi kontaktoni mirëmbajtesin tuaj.
Ne e kuptojmë se kjo nuk është ideale. Në disa raste, përdoruesit humbën të dhënat shtesë (për shembull, të dhënat shtesë Kontejnerë me shumë llogari).
Ky efekt anësor nuk mund të shmangej, por ne besojmë se në afat të shkurtër kemi zgjedhur zgjidhjen më të mirë për shumicën e përdoruesve. Në afat të gjatë, ne do të kërkojmë për qasje të tjera, më të avancuara arkitekturore.
Mësimet
Së pari, ekipi ynë bëri një punë të mrekullueshme duke krijuar dhe dërguar një rregullim në më pak se 12 orë pasi u zbulua problemi. Si dikush që merrte pjesë në mbledhje, mund të them se në këtë situatë të vështirë njerëzit punuan shumë dhe humbën shumë pak kohë.
Natyrisht, asgjë nga këto nuk duhet të kishte ndodhur fare. Është e qartë se ia vlen të rregullojmë proceset tona për të zvogëluar gjasat e incidenteve të tilla dhe për ta bërë më të lehtë riparimin.
Javën e ardhshme do të publikojmë një post-mortem zyrtar dhe një listë të ndryshimeve që synojmë të bëjmë. Tani për tani, unë do të ndaj mendimet e mia. Së pari, duhet të ketë një mënyrë më të mirë për të monitoruar statusin e asaj që është një bombë e mundshme me sahat. Ne duhet të jemi të sigurt se nuk e gjejmë veten në një situatë ku njëri prej tyre funksionon papritur. Ne ende po përpunojmë detajet, por së paku, është e nevojshme të merren parasysh të gjitha këto gjëra.
Së dyti, ne kemi nevojë për një mekanizëm për të ofruar shpejt përditësime tek përdoruesit, edhe kur—veçanërisht kur—çdo gjë tjetër dështon. Ishte mirë që ne mundëm të përdornim sistemin e "kërkimit", por ai është një mjet i papërsosur dhe ka disa efekte anësore të padëshiruara. Në veçanti, ne e dimë se shumë përdorues kanë përditësime automatike të aktivizuara, por do të preferonin të mos merrnin pjesë në kërkime (e pranoj, edhe unë i kam të fikur!). Në të njëjtën kohë, ne kemi nevojë për një mënyrë për t'u dërguar përditësime përdoruesve, por pavarësisht nga zbatimi i brendshëm teknik, përdoruesit duhet të jenë në gjendje të abonohen në përditësime (përfshirë rregullimet e nxehta), por të zgjedhin çdo gjë tjetër. Për më tepër, kanali i përditësimit duhet të jetë më i përgjegjshëm se sa është aktualisht. Edhe më 6 maj, ka pasur ende përdorues që nuk kanë përfituar as nga rregullimi, as nga versioni i ri. Ky problem tashmë është punuar, por ajo që ndodhi tregoi se sa e rëndësishme është.
Së fundi, ne do t'i hedhim një vështrim më të afërt arkitekturës së sigurisë së shtesës për t'u siguruar që ofron nivelin e duhur të sigurisë me rrezik minimal për të prishur ndonjë gjë.
Javën e ardhshme do të shikojmë rezultatet e një analize më të plotë të asaj që ndodhi, por ndërkohë do të jem i lumtur t'u përgjigjem pyetjeve me email: [email mbrojtur]
Burimi: linux.org.ru