Pastaba vertėjas: skaitytojų patogumui datos nurodytos Maskvos laiku
Neseniai nepasibaigė vieno iš sertifikatų, naudojamų priedams pasirašyti, galiojimo laikas. Dėl to priedai buvo išjungti vartotojams. Dabar, kai problema dažniausiai išspręsta, norėčiau pasidalinti smulkmenomis apie tai, kas nutiko ir atliktus darbus.
Fonas: papildymai ir parašai
Įdiegti priedai turi turėti Elektroninis parašas, kuri apsaugo vartotojus nuo kenkėjiškų priedų ir reikalauja minimalaus „Mozilla“ personalo priedų peržiūros. Šį reikalavimą įvedėme 2015 m., nes patyrėme rimtų problemų su kenkėjiškais priedais.
Kaip tai veikia: kiekvienoje „Firefox“ kopijoje yra „šakninis sertifikatas“. Šios „šaknies“ raktas yra saugomas Aparatinės įrangos saugos modulis (HSM)be prieigos prie tinklo. Kas kelerius metus šiuo raktu pasirašomas naujas „tarpinis sertifikatas“, kuris naudojamas pasirašant priedus. Kai kūrėjas pateikia priedą, mes sukuriame laikiną „pabaigos sertifikatą“ ir pasirašome jį naudodami tarpinį sertifikatą. Tada pats priedas pasirašomas galutiniu sertifikatu. Schematiškai atrodo taip.
Atkreipkite dėmesį, kad kiekvienas sertifikatas turi „subjektą“ (kam buvo išduotas sertifikatas) ir „išdavėją“ (išdavė sertifikatą). Šakninio sertifikato atveju „subject“ = „išdavėjas“, tačiau kitų sertifikatų atveju sertifikato išdavėjas yra pirminio sertifikato, kuriuo jis pasirašytas, subjektas.
Svarbus dalykas: kiekvienas priedas yra pasirašytas unikaliu pabaigos sertifikatu, tačiau beveik visada šie galutiniai sertifikatai yra pasirašomi tuo pačiu tarpiniu sertifikatu.
Autoriaus pastaba: Išimtis yra labai seni papildymai. Tuo metu buvo naudojami įvairūs tarpiniai sertifikatai.
Šis tarpinis sertifikatas sukėlė problemų: kiekvienas sertifikatas galioja tam tikrą laikotarpį. Prieš arba po šio laikotarpio sertifikatas negalioja ir naršyklė nenaudos priedų, pasirašytų šiuo sertifikatu. Deja, tarpinio pažymėjimo galiojimas baigėsi gegužės 4 dieną 4 val.
Pasekmės pasireiškė ne iš karto. „Firefox“ įdiegtų priedų parašus tikrina ne nuolat, o maždaug kartą per 24 valandas, o tikrinimo laikas kiekvienam vartotojui yra individualus. Dėl to kai kurie žmonės problemas pajuto iš karto, kiti – daug vėliau. Pirmą kartą apie problemą sužinojome maždaug tuo metu, kai pasibaigė sertifikato galiojimas, ir iškart pradėjome ieškoti sprendimo.
Žalos mažinimas
Supratę, kas atsitiko, stengėmės, kad situacija nepablogėtų.
Pirma, jie nustojo priimti ir pasirašyti naujus papildymus. Nėra prasmės tam naudoti pasibaigusio sertifikato. Žvelgdamas atgal, sakyčiau, kad galėjome viską palikti taip, kaip buvo. Dabar atnaujinome papildų priėmimą.
Antra, jie iš karto išsiuntė pataisą, kuri neleido kasdien tikrinti parašų. Taip išgelbėjome tuos vartotojus, kurių naršyklė per pastarąsias XNUMX valandas dar neturėjo laiko patikrinti priedų. Šis pataisymas buvo atšauktas ir nebereikalingas.
Lygiagretus veikimas
Teoriškai problemos sprendimas atrodo paprastas: sukurti naują galiojantį tarpinį sertifikatą ir iš naujo pasirašyti kiekvieną priedą. Deja, tai neveiks:
- negalime greitai perrašyti iš karto 15 tūkstančių priedų, sistema tokiai apkrovai nesukurta
- Pasirašius priedus, atnaujintos versijos turi būti pristatytos vartotojams. Dauguma priedų yra įdiegiami iš „Mozilla“ serverių, todėl „Firefox“ naujinimus suras per artimiausias XNUMX valandas, tačiau kai kurie kūrėjai platina pasirašytus priedus per trečiųjų šalių kanalus, todėl naudotojai turėtų atnaujinti tokius priedus rankiniu būdu.
Vietoj to bandėme sukurti pataisą, kuri pasiektų visus vartotojus, nereikalaujant daug ar jokių veiksmų.
Gana greitai priėjome prie dviejų pagrindinių strategijų, kurias naudojome lygiagrečiai:
- Atnaujinkite „Firefox“, kad pakeistumėte sertifikato galiojimo laikotarpį. Dėl to esami priedai vėl stebuklingai veiks, tačiau reikės išleisti ir išsiųsti naują „Firefox“ versiją
- Sukurkite galiojantį sertifikatą ir kažkaip įtikinkite „Firefox“ jį priimti, o ne esamą, kurio galiojimo laikas pasibaigęs
Pirmiausia nusprendėme pasinaudoti pirmąja parinktimi, kuri atrodė gana veiksminga. Dienos pabaigoje jie išleido antrą pataisą (naują sertifikatą), apie kurį kalbėsime vėliau.
Sertifikato pakeitimas
Kaip minėjau aukščiau, reikėjo:
- sukurti naują galiojantį sertifikatą
- įdiekite jį nuotoliniu būdu Firefox
Norėdami suprasti, kodėl tai veikia, atidžiau pažvelkime į priedo patvirtinimo procesą. Pats priedas pateikiamas kaip failų rinkinys, įskaitant pasirašymui naudojamų sertifikatų grandinę. Dėl to priedas gali būti patikrintas, jei naršyklė žino šakninį sertifikatą, kuris kūrimo metu yra integruotas į „Firefox“. Tačiau, kaip jau žinome, tarpinis sertifikatas pasibaigė, todėl papildinio patikrinti neįmanoma.
Kai „Firefox“ bando patikrinti priedą, jis neapsiriboja sertifikatų, esančių pačiame priede, naudojimu. Vietoj to, naršyklė bando sukurti galiojančią sertifikatų grandinę, pradedant nuo pabaigos sertifikato ir tęsiant, kol pasiekia šaknį. Pirmajame lygyje pradedame nuo pabaigos sertifikato ir tada randame sertifikatą, kurio subjektas yra pabaigos sertifikato (tai yra tarpinio sertifikato) išdavėjas. Paprastai šis tarpinis sertifikatas pateikiamas kartu su priedu, bet bet koks sertifikatas iš naršyklės saugyklos taip pat gali būti naudojamas kaip šis tarpinis sertifikatas. Jei galime nuotoliniu būdu pridėti naują galiojantį sertifikatą prie sertifikatų saugyklos, „Firefox“ bandys jį naudoti. Situacija prieš ir po naujo sertifikato įdiegimo.
Įdiegę naują sertifikatą, „Firefox“ turės dvi parinktis tikrindama sertifikatų grandinę: naudoti seną negaliojantį sertifikatą (kuris neveiks) arba naują galiojantį sertifikatą (kuris veiks). Svarbu, kad naujajame sertifikate būtų toks pat subjekto pavadinimas ir viešasis raktas kaip ir senajame sertifikate, todėl jo parašas galutiniame sertifikate galios. „Firefox“ yra pakankamai protinga, kad išbandytų abi parinktis, kol randa tą, kuri veikia, todėl priedai vėl bus išbandyti. Atminkite, kad tai yra ta pati logika, kurią naudojame TLS sertifikatams patvirtinti.
Autoriaus pastaba: su WebPKI susipažinę skaitytojai pastebės, kad kryžminiai sertifikatai veikia lygiai taip pat.
Puikus šio pataisymo dalykas yra tai, kad nereikia iš naujo pasirašyti esamų priedų. Kai tik naršyklė gaus naują sertifikatą, visi priedai vėl veiks. Likęs iššūkis yra pateikti naują sertifikatą vartotojams (automatiškai ir nuotoliniu būdu), taip pat priversti „Firefox“ dar kartą patikrinti išjungtus priedus.
Normandija ir tyrimų sistema
Ironiška, bet šią problemą išsprendžia specialus priedas, vadinamas „sistema“. Norėdami atlikti tyrimus, sukūrėme sistemą, pavadintą Normandija, kuri vartotojams teikia tyrimus. Šie tyrimai automatiškai atliekami naršyklėje ir turi patobulintą prieigą prie „Firefox“ vidinių API. Tyrimas gali pridėti naujų sertifikatų į sertifikatų saugyklą.
Autoriaus pastaba: Mes nepridedame sertifikato su jokiomis specialiomis privilegijomis; jis pasirašytas šakniniu sertifikatu, todėl „Firefox“ juo pasitiki. Tiesiog įtraukiame jį į sertifikatų, kuriuos gali naudoti naršyklė, telkinį.
Taigi sprendimas yra sukurti tyrimą:
- įdiegti naują sertifikatą, kurį sukūrėme vartotojams
- priversti naršyklę dar kartą patikrinti išjungtus priedus, kad jie vėl veiktų
„Bet palaukite“, – sakote, „priedai neveikia, kaip paleisti sistemos priedą? Pasirašykime su nauju sertifikatu!
Viską sudėjus... kodėl tai užtrunka taip ilgai?
Taigi, planas: išduoti naują sertifikatą, kuris pakeis senąjį, sukurti sistemos priedą ir įdiegti jį vartotojams per Normandiją. Problemos, kaip sakiau, prasidėjo gegužės 4 d. 4:00, o jau tos pačios dienos 12:44, nepraėjus 9 valandoms, išsiuntėme pataisą į Normandiją. Prireikė dar 6–12 valandų, kol jis pasiekė visus vartotojus. Visai neblogai, bet „Twitter“ žmonės klausia, kodėl negalėjome veikti greičiau.
Pirma, prireikė laiko išduoti naują tarpinį pažymėjimą. Kaip minėjau aukščiau, šakninio sertifikato raktas saugomas neprisijungus prie aparatūros saugos modulio. Saugumo požiūriu tai yra gerai, nes šaknis naudojamas labai retai ir turėtų būti patikimai apsaugotas, tačiau tai yra šiek tiek nepatogu, kai reikia skubiai pasirašyti naują sertifikatą. Vienas iš mūsų inžinierių turėjo keliauti į HSM saugyklą. Tada buvo nesėkmingų bandymų išduoti teisingą sertifikatą ir kiekvienas bandymas kainavo vieną ar dvi valandas, praleistas testavimui.
Antra, sistemos priedo kūrimas užtruko. Konceptualiai tai labai paprasta, tačiau net ir paprastos programos reikalauja priežiūros. Norėjome įsitikinti, kad nepabloginsime situacijos. Tyrimai turi būti išbandyti prieš juos siunčiant vartotojams. Be to, priedas turi būti pasirašytas, tačiau mūsų priedų pasirašymo sistema buvo išjungta, todėl turėjome rasti sprendimą.
Galiausiai, kai jau buvome paruošę pateikti tyrimą, diegimas užtruko. Naršyklė kas 6 valandas tikrina, ar nėra Normandijos naujinimų. Ne visi kompiuteriai visada yra įjungti ir prijungti prie interneto, todėl prireiks laiko, kol pataisa išplis vartotojams.
Paskutiniai žingsniai
Tyrimas turėtų išspręsti problemą daugeliui vartotojų, tačiau nėra prieinamas visiems. Kai kuriems vartotojams reikalingas specialus požiūris:
- vartotojų, kurie išjungė tyrimus ar telemetriją
- „Android“ versijos („Fennec“) naudotojų, kur tyrimai visiškai nepalaikomi
- tinkintų „Firefox ESR“ versijų naudotojai įmonėse, kuriose negalima įjungti telemetrijos
- vartotojai, sėdintys už MitM tarpinių serverių, nes mūsų priedų diegimo sistema naudoja raktų prisegimą, kuris neveikia su tokiais tarpiniais serveriais
- senų „Firefox“ versijų, kurios nepalaiko tyrimų, naudotojai
Dėl pastarosios vartotojų kategorijos nieko negalime padaryti – jie vis tiek turėtų atsinaujinti į naują „Firefox“ versiją, nes pasenusiose yra rimtų nepataisytų spragų. Žinome, kad kai kurie žmonės naudojasi senesnėmis „Firefox“ versijomis, nes nori paleisti senus priedus, tačiau daugelis senų priedų jau buvo perkelti į naujesnes naršyklės versijas. Kitiems vartotojams sukūrėme pataisą, kuri įdiegs naują sertifikatą. Jis buvo išleistas kaip klaidų taisymo leidimas (vertėjo pastaba: Firefox 66.0.5), todėl žmonės jį gaus – greičiausiai jau gavo – per įprastą atnaujinimo kanalą. Jei naudojate tinkintą Firefox ESR versiją, susisiekite su savo prižiūrėtoju.
Suprantame, kad tai nėra idealu. Kai kuriais atvejais vartotojai prarado papildomus duomenis (pavyzdžiui, papildomus duomenis Kelių sąskaitų konteineriai).
Šio šalutinio poveikio nepavyko išvengti, tačiau manome, kad per trumpą laiką daugumai vartotojų pasirinkome geriausią sprendimą. Ilgainiui ieškosime kitų, pažangesnių architektūrinių metodų.
Pamokos
Pirma, mūsų komanda atliko nuostabų darbą kurdama ir pristatydama pataisą per mažiau nei 12 valandų po to, kai buvo aptikta problema. Kaip susitikimų dalyvis galiu pasakyti, kad šioje sudėtingoje situacijoje žmonės labai sunkiai dirbo ir buvo sugaištama labai mažai laiko.
Akivaizdu, kad iš viso to neturėjo atsitikti. Akivaizdu, kad verta koreguoti savo procesus, kad sumažintume tokių incidentų tikimybę ir palengvintume ištaisymą.
Kitą savaitę paskelbsime oficialų postmortem ir pakeitimų, kuriuos ketiname atlikti, sąrašą. Kol kas pasidalinsiu savo mintimis. Pirma, turi būti geresnis būdas stebėti potencialios uždelsto veikimo bombos būseną. Turime būti tikri, kad neatsiduriame situacijoje, kai vienas iš jų staiga suveikia. Detales vis dar aiškinamės, bet bent jau į visus tokius dalykus būtina atsižvelgti.
Antra, mums reikia mechanizmo, leidžiančio greitai pateikti naujinimus vartotojams, net kai (ypač kai) visa kita nepavyksta. Puiku, kad galėjome pasinaudoti „tyrimų“ sistema, tačiau tai netobulas įrankis ir turi tam tikrų nepageidaujamų šalutinių poveikių. Visų pirma, žinome, kad daugelis vartotojų yra įjungę automatinius naujinimus, bet nenorėtų dalyvauti tyrimuose (pripažįstu, aš juos taip pat išjungiau!). Tuo pačiu metu mums reikia būdo, kaip siųsti naujinimus vartotojams, tačiau kad ir koks būtų vidinis techninis įgyvendinimas, vartotojai turėtų turėti galimybę prenumeruoti naujinimus (įskaitant karštąsias pataisas), bet atsisakyti viso kito. Be to, atnaujinimo kanalas turėtų būti jautresnis nei dabar. Net ir gegužės 6 dieną vis dar buvo vartotojų, kurie nepasinaudojo nei pataisymu, nei nauja versija. Ši problema jau buvo išspręsta, bet tai, kas įvyko, parodė, kokia ji svarbi.
Galiausiai atidžiau pažvelgsime į priedo saugos architektūrą, kad įsitikintume, jog jis užtikrina tinkamą saugumo lygį su minimalia rizika ką nors sugadinti.
Kitą savaitę pažvelgsime į išsamesnės to, kas nutiko, analizės rezultatus, bet kol kas mielai atsakysiu į klausimus el. paštu: [apsaugotas el. paštu]
Šaltinis: linux.org.ru