Märge tõlkija: lugejate mugavuse huvides on kuupäevad antud Moskva aja järgi
Hiljuti jätsime vahele ühe lisandmoodulite allkirjastamiseks kasutatava sertifikaadi aegumise. Selle tulemusel keelati kasutajate jaoks lisandmoodulid. Nüüd, kus probleem on valdavalt lahendatud, tahaksin jagada juhtunu ja tehtud töö üksikasju.
Taust: täiendused ja allkirjad
Installitud lisandmoodulitel peab olema digitaalne allkiri, mis kaitseb kasutajaid pahatahtlike lisandmoodulite eest ja nõuab Mozilla töötajate minimaalset lisandmoodulite ülevaatamist. Võtsime selle nõude kasutusele 2015. aastal, kuna kogesime tõsiseid probleeme pahatahtlike lisandmoodulitega.
Kuidas see töötab: iga Firefoxi koopia sisaldab juursertifikaati. Selle "juure" võti on salvestatud Riistvara turbemoodul (HSM)ilma juurdepääsuta võrgule. Iga paari aasta tagant allkirjastatakse selle võtmega uus “vahesertifikaat”, mida kasutatakse lisandmoodulite allkirjastamisel. Kui arendaja esitab lisandmooduli, loome ajutise "lõppsertifikaadi" ja allkirjastame selle vahesertifikaadi abil. Seejärel allkirjastatakse lisandmoodul ise lõpliku sertifikaadiga. Skemaatiliselt see näeb välja selline.
Pange tähele, et igal sertifikaadil on "subjekt" (kellele sertifikaat väljastati) ja "väljaandja" (kes sertifikaadi väljastas). Juursertifikaadi puhul on "subject" = "väljaandja", kuid teiste sertifikaatide puhul on sertifikaadi väljaandja selle vanemsertifikaadi subjekt, millega see on allkirjastatud.
Oluline punkt: iga lisandmoodul on allkirjastatud unikaalse lõppsertifikaadiga, kuid peaaegu alati allkirjastatakse need lõppsertifikaadid sama vahesertifikaadiga.
Autori märkus: Erandiks on väga vanad täiendused. Sel ajal kasutati erinevaid vahesertifikaate.
See vahepealne sertifikaat tekitas probleeme: iga sertifikaat kehtib teatud aja. Enne või pärast seda perioodi on sertifikaat kehtetu ja brauser ei kasuta selle sertifikaadiga allkirjastatud lisandmooduleid. Kahjuks aegus vahetunnistus 4. mail kell 4 hommikul.
Tagajärjed ei ilmnenud kohe. Firefox ei kontrolli installitud lisandmoodulite allkirju pidevalt, vaid ligikaudu kord 24 tunni jooksul ning kontrollimise aeg on iga kasutaja jaoks individuaalne. Selle tulemusena tekkisid mõnedel inimestel probleemid kohe, teistel aga palju hiljem. Saime probleemist esmakordselt teada umbes sertifikaadi aegumise ajal ja hakkasime kohe lahendust otsima.
Kahjustuse vähendamine
Kui juhtunust aru saime, püüdsime olukorra halvenemist ära hoida.
Esiteks lõpetasid nad uute täienduste vastuvõtmise ja allkirjastamise. Selleks pole mõtet kasutada aegunud sertifikaati. Tagantjärele mõeldes ütleksin, et oleksime võinud kõik nii nagu oli. Oleme nüüd jätkanud toidulisandite vastuvõtmist.
Teiseks saatsid nad kohe välja paranduse, mis takistas allkirjade igapäevast kontrollimist. Nii päästsime need kasutajad, kelle brauseris polnud viimase XNUMX tunni jooksul veel jõudnud lisandmooduleid kontrollida. See parandus on nüüd tagasi võetud ja seda pole enam vaja.
Paralleelne töö
Teoreetiliselt tundub probleemi lahendus lihtne: looge uus kehtiv vahesertifikaat ja allkirjastage iga lisandmoodul uuesti. Kahjuks see ei tööta:
- me ei saa 15 tuhat lisandmoodulit korraga kiiresti uuesti allkirjastada, süsteem pole sellise koormuse jaoks mõeldud
- Pärast täienduste allkirjastamist tuleb värskendatud versioonid kasutajatele edastada. Enamik lisandmooduleid installitakse Mozilla serveritest, nii et Firefox leiab värskendused järgmise XNUMX tunni jooksul, kuid mõned arendajad levitavad allkirjastatud lisandmooduleid kolmanda osapoole kanalite kaudu, nii et kasutajad peaksid selliseid lisandmooduleid käsitsi värskendama.
Selle asemel püüdsime välja töötada paranduse, mis jõuaks kõigi kasutajateni, ilma et neilt oleks vaja midagi teha.
Üsna kiiresti jõudsime kahe peamise strateegiani, mida kasutasime paralleelselt:
- Sertifikaadi kehtivusaja muutmiseks värskendage Firefoxi. See paneb olemasolevad lisandmoodulid taas võluväel tööle, kuid nõuab Firefoxi uue versiooni väljaandmist ja tarnimist
- Genereeri kehtiv sertifikaat ja veenda kuidagi Firefoxi seda olemasoleva aegunud sertifikaadi asemel aktsepteerima
Otsustasime esmalt kasutada esimest varianti, mis tundus üsna toimiv. Päeva lõpus andsid nad välja teise paranduse (uue sertifikaadi), millest räägime hiljem.
Sertifikaadi asendamine
Nagu ma eespool mainisin, oli see vajalik:
- luua uus kehtiv sertifikaat
- installige see Firefoxis eemalt
Et mõista, miks see toimib, vaatame lähemalt lisandmooduli kinnitamise protsessi. Lisandmoodul ise on failide komplekt, sealhulgas allkirjastamiseks kasutatavate sertifikaatide ahel. Selle tulemusena saab lisandmoodulit kontrollida, kui brauser teab juursertifikaati, mis on Firefoxi ehitamise ajal sisse ehitatud. Kuid nagu me juba teame, on vahepealne sertifikaat aegunud, mistõttu on lisandmooduli kontrollimine võimatu.
Kui Firefox proovib pistikprogrammi kinnitada, ei piirdu see pistikprogrammis sisalduvate sertifikaatide kasutamisega. Selle asemel proovib brauser luua kehtiva sertifikaadiahela, alustades lõpusertifikaadist ja jätkates, kuni see jõuab juureni. Esimesel tasemel alustame lõpusertifikaadiga ja seejärel leiame sertifikaadi, mille subjektiks on lõppsertifikaadi (ehk siis vahesertifikaadi) väljastaja. Tavaliselt tarnitakse see vahesertifikaat koos lisandmooduliga, kuid selle vahesertifikaadina võib toimida ka mis tahes brauseri salvestusruumi sertifikaat. Kui saame sertifikaadisalve kaugjuhtimisega lisada uue kehtiva sertifikaadi, proovib Firefox seda kasutada. Olukord enne ja pärast uue sertifikaadi paigaldamist.
Pärast uue sertifikaadi installimist on Firefoxil sertifikaadiahela kinnitamisel kaks võimalust: kasutada vana kehtetut sertifikaati (mis ei tööta) või uut kehtivat sertifikaati (mis töötab). Oluline on, et uus sertifikaat sisaldaks sama subjekti nime ja avalikku võtit kui vana sertifikaat, nii et selle allkiri lõplikul sertifikaadil kehtiks. Firefox on piisavalt nutikas, et proovida mõlemat võimalust, kuni leiab sobiva, nii et lisandmooduleid testitakse uuesti. Pange tähele, et see on sama loogika, mida kasutame TLS-sertifikaatide kinnitamiseks.
Autori märkus: WebPKI-ga tuttavad lugejad panevad tähele, et ristsertifikaadid töötavad täpselt samamoodi.
Selle paranduse suurepärane asi on see, et see ei nõua olemasolevate lisandmoodulite uuesti allkirjastamist. Niipea, kui brauser saab uue sertifikaadi, hakkavad kõik lisandmoodulid uuesti tööle. Ülejäänud väljakutse on uue sertifikaadi edastamine kasutajatele (automaatselt ja eemalt) ning Firefoxi keelatud lisandmoodulite uuesti kontrollimine.
Normandia ja uurimissüsteem
Irooniline, et selle probleemi lahendab spetsiaalne lisandmoodul nimega "süsteem". Uuringute läbiviimiseks töötasime välja süsteemi nimega Normandy, mis edastab kasutajatele uuringuid. Need uuringud tehakse brauseris automaatselt ja neil on täiustatud juurdepääs Firefoxi sisemistele API-dele. Uuringud võivad sertifikaadisalve lisada uusi sertifikaate.
Autori märkus: me ei lisa eriõigustega sertifikaati; see on allkirjastatud juursertifikaadiga, nii et Firefox usaldab seda. Lisame selle lihtsalt sertifikaatide hulka, mida brauser saab kasutada.
Nii et lahendus on luua uuring:
- kasutajate jaoks loodud uue sertifikaadi installimine
- sundides brauserit uuesti kontrollima keelatud lisandmooduleid, et need uuesti töötaksid
"Aga oota," ütlete, "lisandmoodulid ei tööta, kuidas ma saan käivitada süsteemi lisandmooduli?" Kirjutame sellele uue tunnistusega!
Kui kõik kokku panna... miks see nii kaua aega võtab?
Niisiis, plaan: väljastada uus sertifikaat vana asemel, luua süsteemi lisandmoodul ja installida see kasutajatele Normandia kaudu. Probleemid, nagu öeldud, algasid 4. mail kell 4:00 ja juba samal päeval kell 12:44, vähem kui 9 tunni pärast, saatsime paranduse Normandiasse. Kõigi kasutajateni jõudmiseks kulus veel 6–12 tundi. Pole üldse paha, aga inimesed Twitteris küsivad, miks me ei oleks võinud kiiremini tegutseda.
Esiteks võttis aega uue vahetunnistuse väljastamine. Nagu ma eespool mainisin, salvestatakse juursertifikaadi võti võrguühenduseta riistvara turvamoodulis. Turvalisuse seisukohast on see hea, kuna juurt kasutatakse väga harva ja see peaks olema usaldusväärselt kaitstud, kuid see on veidi ebamugav, kui peate kiiresti uue sertifikaadi allkirjastama. Üks meie inseneridest pidi sõitma HSM-i hoidlasse. Seejärel üritati õiget sertifikaati väljastada ebaõnnestunult ja iga katse maksis üks-kaks tundi testimiseks.
Teiseks võttis süsteemi lisandmooduli arendamine veidi aega. Põhimõtteliselt on see väga lihtne, kuid isegi lihtsad programmid nõuavad hoolt. Tahtsime olla kindlad, et me ei muudaks olukorda hullemaks. Enne kasutajatele saatmist tuleb uuringuid testida. Lisaks peab lisandmoodul olema allkirjastatud, kuid meie lisandmoodulite allkirjastamise süsteem oli keelatud, seega pidime leidma lahenduse.
Lõpuks, kui olime uuringud esitamiseks valmis, võttis kasutuselevõtt aega. Brauser kontrollib Normandia värskendusi iga 6 tunni järel. Kõik arvutid ei ole alati sisse lülitatud ja Internetti ühendatud, seega võtab paranduse kasutajateni levimine aega.
Viimased sammud
Uuring peaks enamiku kasutajate jaoks probleemi lahendama, kuid see pole kõigile kättesaadav. Mõned kasutajad vajavad erilist lähenemist:
- kasutajad, kes on keelanud uurimistöö või telemeetria
- Androidi versiooni (Fennec) kasutajad, kus uurimistööd üldse ei toetata
- Firefox ESR-i kohandatud järgu kasutajad ettevõtetes, kus telemeetriat ei saa lubada
- MitM-i puhverserverite taga istuvad kasutajad, kuna meie lisandmoodulite installisüsteem kasutab võtme kinnitamist, mis selliste puhverserveritega ei tööta
- Firefoxi pärandversioonide kasutajad, kes ei toeta uurimistööd
Viimase kasutajakategooriaga ei saa me midagi ette võtta – nad peaksid siiski Firefoxi uuele versioonile värskendama, sest vananenud on tõsiseid parandamata turvaauke. Teame, et mõned inimesed jäävad Firefoxi vanemate versioonide juurde, kuna soovivad käitada vanu lisandmooduleid, kuid paljud vanad lisandmoodulid on juba üle viidud brauseri uuematesse versioonidesse. Teiste kasutajate jaoks oleme välja töötanud plaastri, mis installib uue sertifikaadi. See anti välja veaparandusena (tõlkija märkus: Firefox 66.0.5), nii et inimesed saavad selle – tõenäoliselt juba said – tavalise värskenduskanali kaudu. Kui kasutate kohandatud Firefox ESR-i versiooni, võtke ühendust oma hooldajaga.
Mõistame, et see pole ideaalne. Mõnel juhul kaotasid kasutajad lisandandmed (nt lisandandmed Mitme konto mahutid).
Seda kõrvalmõju ei olnud võimalik vältida, kuid usume, et lühiajaliselt oleme valinud enamiku kasutajate jaoks parima lahenduse. Pikemas perspektiivis otsime teisi, arenenumaid arhitektuurilisi lähenemisviise.
Õppetunnid
Esiteks tegi meie meeskond suurepärase töö, luues ja saatis paranduse vähem kui 12 tunni jooksul pärast probleemi avastamist. Koosolekutel käijana võin öelda, et selles keerulises olukorras töötati väga palju ja aega kulus väga vähe.
Ilmselgelt poleks seda pidanud üldse juhtuma. Ilmselgelt tasub meie protsesse kohandada, et vähendada selliste juhtumite tõenäosust ja muuta heastamine lihtsamaks.
Järgmisel nädalal avaldame ametliku surmajärgse aruande ja muudatuste nimekirja, mida kavatseme teha. Praegu jagan oma mõtteid. Esiteks peab olema parem viis potentsiaalse viitsütikuga pommi oleku jälgimiseks. Peame olema kindlad, et me ei satu olukorrast, kus mõni neist äkki toimib. Me alles töötame välja üksikasjad, kuid vähemalt on vaja kõiki selliseid asju arvesse võtta.
Teiseks vajame mehhanismi värskenduste kiireks kasutajatele edastamiseks isegi siis, kui kõik muu ebaõnnestub. Tore, et saime kasutada "uuringute" süsteemi, kuid see on ebatäiuslik tööriist ja sellel on mõned soovimatud kõrvalmõjud. Eelkõige teame, et paljudel kasutajatel on automaatsed värskendused sisse lülitatud, kuid nad eelistaksid uuringus mitte osaleda (möönan, et ka mul on need välja lülitatud!). Samal ajal vajame viisi, kuidas kasutajatele värskendusi saata, kuid olenemata sisemisest tehnilisest teostusest peaksid kasutajad saama tellida värskendusi (sh kiirparandusi), kuid loobuma kõigest muust. Lisaks peaks värskenduskanal olema praegusest tundlikum. Isegi 6. mail leidus endiselt kasutajaid, kes ei kasutanud ei parandust ega uut versiooni. Selle probleemiga on juba tööd tehtud, kuid juhtunu näitas, kui oluline see on.
Lõpetuseks vaatame lähemalt lisandmooduli turbearhitektuuri, veendumaks, et see tagab õige turbetaseme minimaalse rikkumisriskiga.
Järgmisel nädalal vaatame juhtunu põhjalikuma analüüsi tulemusi, seni aga vastan meeleldi küsimustele meili teel: [meiliga kaitstud]
Allikas: linux.org.ru