Tehnilised üksikasjad hiljutisest laiendite keelamisest Firefoxis

Märkus: kasutajate mugavuse huvides on kuupäevad toodud Moskva aja järgi

Hiljuti jätsime tähelepanuta ühe sertifikaadi aegumise, mida kasutati lisandite allkirjastamiseks. See viis lisandite keelamiseni kasutajatel. Nüüd, kui vähemalt enamus probleemist on lahendatud, soovin rääkida juhtunust ja tehtud tööst.

Taust: lisandid ja allkirjad

Kuigi paljud kasutavad brauserit "karbist välja", toetab Firefox laiendusi, mida kutsutakse "lisanditeks". Nende abil saavad kasutajad oma brauserisse erinevaid funktsioone lisada. Üle 15 000 lisandi on saadaval: alates reklaamide blokeerimisest kuni saja kaane haldamiseni.

Paigaldatud lisanditel peab olema digitaalne allkiri, mis kaitseb kasutajaid pahavara sisaldavate lisandite eest ning nõuab minimaalset lisandite kontrollimist Mozilla töötajate poolt. Me kehtestasime selle nõude 2015. aastal, kuna kogesime tõsiseid probleeme pahatahtlike lisanditega.

Kuidas see töötab: iga Firefoxi koopia sisaldab "juursertifikaati". Selle "juure" võtmed hoitakse riistvara kaitsemoodulis (HSM), millele puudub ligipääs internetile. Iga paari aasta tagant allkirjastatakse nende võtmega uus "vahesertifikaat", mida kasutatakse lisandite allkirjastamisel. Kui arendaja saadab lisandi, loome ajutise "lõppsertifikaadi" ja allkirjastame selle, kasutades vahesertifikaati. Seejärel allkirjastatakse lisandi ise lõppsertifikaadiga. Skeemiliselt näeb see välja nii.

Pange tähele: iga sertifikaadil on "subjekt" (kellele sertifikaat on antud) ja "väljastaja" (kes sertifikaadi välja andis). Juursertifikaadi puhul on "subjekt" = "väljastaja", kuid teiste sertifikaatide puhul on väljastaja sertifikaadi ülemise taseme sertifikaadi subjekt, mida see allkirjastas.

Oluline punkt: iga lisand on allkirjastatud ainulaadse lõppsertifikaadiga, kuid peaaegu alati on need lõppsertifikaadid allkirjastatud ühe ja sama vahesertifikaadiga.

Autori märkus: erandiks on väga vanad lisandid. Sel ajal kasutati erinevaid vahesertifikaate.

See vahesertifikaat tekitas probleeme: iga sertifikaat kehtib teatud aja jooksul. Enne või pärast seda perioodi on sertifikaat kehtetu ja brauser ei kasuta selle sertifikaadiga allkirjastatud lisasid. Kahjuks aegus vahesertifikaadi kehtivus 4. mail kell 4 hommikul.

Tagajärjed ei ilmunud kohe. Firefox ei kontrolleeri installitud lisade allkirju pidevalt, vaid umbes iga 24 tunni järel, kontrollimise aeg on iga kasutaja jaoks individuaalne. Seetõttu tekkisid probleemid mõnel inimesel kohe, teistel aga palju hiljem. Saime probleemist esmakordselt teada just siis, kui sertifikaadi kehtivus lõppes, ja alustasime kohe lahenduse otsimist.

Kahjude vähendamine

Niipea kui me aru saime, mis juhtus, püüdsime olukorra halvenemist vältida.

Esiteks, lõpetasime uute lisade vastuvõtmise ja allkirjastamise. Pole mõtet kasutada selleks aegunud sertifikaati. Tagasi vaadates, võiksin öelda, et oleks võinud kõik jätta nii, nagu see oli. Praegu on lisade vastuvõtmine taasalustatud.

Teiseks, saatsime kohe välja paranduse, mis katkis igapäevase allkirjade kontrolli. Nii päästsime need kasutajad, kelle brauser ei olnud viimase 24 tunni jooksul veel kontrollinud lisasid. Praegu on see parandamine tagasi võetud, selle jaoks ei ole enam vajadust.

Paralleeltöö

Teoreetiliselt näeb probleemi lahendus välja lihtne: loome uue kehtiva vahesertifikaadi ja allkirjastame kõik lisad uuesti. Kahjuks see ei toimi:

• me ei saa kiiresti allkirjastada 15 tuhat lisandit korraga, süsteem ei ole selleks ette valmistatud
• pärast lisade allkirjastamist peab uuendatud versioonid kasutajateni toimetama. Enamik lisasid installitakse Mozilla serveritest, seetõttu leiab Firefox järgmise 24 tunni jooksul uuendusi, kuid mõned arendajad levitavad allkirjastatud lisasid kolmandate osapoolte kanalite kaudu, mistõttu peavad kasutajad selliseid lisasid käsitsi uuendama

Selle asemel püüdsime välja töötada paranduse, mis jõuaks kõikide kasutajateni, nõudes samal ajal (või peaaegu mitte nõudes) nende poolt tegevusi.

Meie jõudsime üsna kiiresti kahe peamise strateegiani, mida kasutasime samaaegselt:

• Uuendage Firefoxi, et muuta sertifikaadi kehtivusperioodi. See muudab olemasolevad laiendused taas tööle, kuid nõuab uue Firefoxi versiooni väljastamist ja tootmist.
• Looge kehtiv sertifikaat ja pange Firefox kuidagi sellele uuele sertifikaadile üle minema, mitte kehtivuse lõppemisega sertifikaadile.

Otsustasime kõigepealt kasutada esimest varianti, mis tundus töötavat. Päeva lõpuks väljastasime ka teise paranduse (uue sertifikaadi), millest räägime hiljem.

Sertifikaadi asendamine

Nagu ma juba eespool mainisin, oli vajalik:

• luua uus kehtiv sertifikaat
• installida see kaugjuhtimise teel Firefoxi

Et mõista, miks see töötab, vaatame lähemalt lisandi kontrollimise protsessi. Lisand ise on komplekt failidest, sealhulgas sertifikaatide ahel, mida kasutatakse allkirjastamiseks. Seetõttu saab lisandit kontrollida, kui brauserile on tuntud juurersertifikaat, mis on Firefoxi paigaldamise ajal sisse ehitatud. Kuid nagu oleme juba teada saanud, on vahe-sertifikaat aegunud, seega pole lisandi kontrollimine võimalik.

Kui Firefox proovib lisandit kontrollida, ei piirdud ta sertifikaatide kasutamisega, mis sisaldavad endas lisandit. Selle asemel püüab brauser luua kehtivat sertifikaatide ahelat, alustades lõppsertifikaadist ja jätkates, kuni jõutakse juureni. Esimeses astmes alustame lõppsertifikaadiga ja seejärel leiame sertifikaadi, mille subjekt on lõppsertifikaadi väljaandja (st vahe-sertifikaat). Tavaliselt tarnitakse see vahe-sertifikaat koos lisandiga, kuid sellel rollil võib olla ka mis tahes sertifikaat brauseri sertifikaadipoest. Kui suudame kaugjuhtimise teel lisada sertifikaadipoe uue kehtiva sertifikaadi, püüab Firefox seda kasutada. Olukord enne ja pärast uue sertifikaadi paigaldamist.

Pärast uue sertifikaadi installimist on Firefox-il kaks võimalust sertifikaadiketju kontrollimisel: kasutada vana kehtetuks tunnistatud sertifikaati (mis ei tööta) või uut kehtivat (mis töötab). Oluline on, et uus sertifikaat sisaldab samu subjektinimesid ja avalikku võtit, mis on vanas sertifikaadis, seetõttu on selle allkiri lõppsertifikaadil kehtiv. Firefox on piisavalt nutikas, et proovida mõlemat varianti, kuni leiab töötava, seega saavad laiendused taas kontrollitud. Pange tähele, et see on sama loogika, mida me TLS sertifikaatide kontrollimisel kasutame.

Autor märkus: lugejad, kes tunnevad WebPKI-d, märkavad, et samuti toimivad ristsertifikaadid.

Selle paranduse juures on kõige tähelepanuväärsem see, et see ei nõua olemasolevate lisade uuesti allkirjastamist. Niipea kui brauser saab uue sertifikaadi, töötavad kõik lisad jälle. Jääb keerukaks see, kuidas tarnida uus sertifikaat kasutajatele (automaatsete ja kaugjõul) ning sundida Firefoxit kontrollima keelatud lisasid uuesti.

Normandy ja uurimissüsteem

Ironiaga lahendab selle probleemi spetsiaalne lisand, mida nimetatakse 'süsteemseks'. Uuringute läbiviimiseks oleme välja töötanud süsteemi nimega Normandy, mis toimetab uuringud kasutajateni. Need uuringud viiakse automaatselt läbi brauseris ja neil on ulatuslik ligipääs Firefoxi sisemistele API-dele. Uuringud saavad lisada uusi sertifikaate sertifikaatide ladustamisse.

Autor märkus: me ei lisa sertifikaati mingite eriliste privileegidega; see on allkirjastatud juursusertifikaadiga, seega usaldab Firefox seda. Me lihtsalt lisame selle sertifikaatide hulka, mida brauser saab kasutada.

Seega seisneb lahendus uuringu koostamises:

• mis paigaldab kasutajatele meie koostatud uue sertifikaadi
• mis sunnib brauserit kontrollima keelatud lisasid, et need uuesti tööle hakkaksid

„Aga oota,” ütled sa, „lisad ei tööta, kuidas käivitada süsteemne lisand?“. Allkirjastame selle uue sertifikaadiga!

Kogume kõik kokku… miks see nii kaua aega võtab?

Nii, plaan: välja anda uus sertifikaat vana asendamiseks, luua süsteemilisand ja paigaldada see kasutajatele läbi Normandy. Probleemid, nagu ma juba ütlesin, algasid 4. mail kell 4:00 ja juba kell 12:44 samal päeval, vähem kui 9 tunni pärast, saatsime paranduse Normandy. Veel kulus 6-12 tundi, et see jõuaks kõikide kasutajateni. Juba mitte paha, aga kasutajad Twitteris küsivad, miks me ei saanud kiiremini tegutseda.

Esiteks, uue vahe-sertifikaadi väljaandmiseks kulus aega. Nagu ma juba varem mainisin, on juursertifikaadi võtmed isoleeritud turvahoidlas. See on hea turvalisuse seisukohalt, kuna juurt kasutatakse väga harva ja see peab olema korralikult kaitstud, kuid see on veidi ebamugav, kui on vaja kiiresti uut sertifikaati allkirjastada. Üks meie inseneridest pidi minema HSM hoiukohta. Seejärel olid ebaõnnestunud katsed välja anda õiget sertifikaati, iga katse nõudis ühe kuni kahe tunni kulutamist testimisele.

Teiseks, süsteemilisandi arendamine võttis aega. Kontseptuaalselt on see väga lihtne, kuid isegi lihtsad programmid nõuavad tähelepanu. Me tahtsime veenduda, et me ei halvendaks olukorda veelgi. Uuringut tuleb enne kasutajatele saatmist testida. Lisaks peab lisand olema allkirjastatud, kuid meie lisandite allkirjastamise süsteem oli väljalülitatud, seega pidime leidma vea, kuidas vältida.

Lõpuks, pärast seda, kui olime uuringud saatmiseks ette valmistanud, kulus nende juurutamiseks aega. Brauser kontrollib Normandy uuenduste olemasolu iga 6 tunni järel. Mitte kõik arvutid ei ole pidevalt sisse lülitatud ja internetiühenduses, seega kulub aega, et parandust kasutajate seas levitada.

Lõppastmed

Uuring peaks enamikul kasutajatel probleemi lahendama, kuid see ei ole kõigile kättesaadav. Mõne kasutajaga on vaja erilist lähenemist:

• kasutajad, kes on uuringud või telemeetria välja lülitanud
• Androidi versiooni (Fennec) kasutajad, kus uuringud ei ole üldse toetatud
• kohandatud Firefox ESR versioonide kasutajad ettevõtetes, kus telemeetria lubamine ei ole võimalik
• kasutajad, kes on MitM-proksi taga, kuna meie lisandmoodulite installimise süsteem kasutab võtme sidumist (key pinning), mis ei toimi selliste proksidega
• vanade Firefoxi versioonide kasutajad, mis ei toeta uurimisi

Me ei saa midagi teha viimase kategooria kasutajatega — neil on ikkagi soovitatav uuendada uusimale Firefoxi versioonile, kuna vanadel versioonidel on tõsised lahendamatud haavatavused. Teame, et mõned inimesed jäävad vanadele Firefoxi versioonidele, et käivitada vanu lisandeid, kuid paljusid vanu lisandeid on juba uute brauseri versioonide jaoks portitud. Ülejäänud kasutajate jaoks oleme välja töötanud plaastri, mis paigaldab uue sertifikaadi. See anti välja bugfix-versioonina (tõlkija märkus: Firefox 66.0.5), seega saavad inimesed selle — tõenäoliselt on nad selle juba saanud — kaudu tavapärast uuenduste kanalit. Kui kasutate kohandatud Firefox ESR taastamist, võtke ühendust oma hooldajaga.

Mõistame, et see ei ole ideaalne. Mõnedel juhtudel on kasutajad kaotanud lisandite andmed (näiteks lisandi andmed Multi-Account Containers).

Seda kõrvaltoimet ei õnnestunud vältida, kuid usume, et lühikeses perspektiivis valisime enamiku kasutajate jaoks parima lahenduse. Pikaajalisemal perioodil uurime muid täiustatud arhitektuurilisi lähenemisviise.

Õppetunnid

Esiteks on meie meeskond teinud uskumatut tööd, luues ja saadetades paranduse vähem kui 12 tunni jooksul pärast probleemi avastamist. Inimesena, kes osales koosolekutel, võin öelda, et selles keerulises olukorras töötasid inimesed väga kõvasti ja aega raisati tõeliselt vähe.

On ilmne, et seda kõike ei oleks tohtinud juhtuda. Selgelt tuleb kohandada meie protsesse, et vähendada sarnaste juhtumite tõenäosust ja lihtsustada tagajärgede lahendamist.

Järgmisel nädalal avaldame ametliku post-mortemi ja nimekirja muudatustest, mida kavatseme teha. Praegu jagan oma mõtteid. Esiteks peaks olema parem viis jälgida potentsiaalsete pommide seisundit. Peame olema kindlad, et me ei satuks olukorda, kus üks neist äkki plahvatab. Me töötame veel üksikasjade kallal, kuid vähemalt on vajalik kõigi selliste asjade arvesse võtmine.

Teiseks on vajalik mehhanism, millega kiiresti kasutajatele värskendusi edastada, isegi siis, kui – eriti siis – kõik muu ei tööta. Oli tore, et saime kasutada 'uurimiste' süsteemi, kuid see ei ole täiuslik tööriist ja tal on mõned soovimatud kõrvaltoimed. Eeskätt teame, et paljudel kasutajatel on automaatne värskendamine sisse lülitatud, kuid nad eelistaksid mitte osaleda uuringutes (pean tunnistama, et ka minul on need välja lülitatud!). Samal ajal vajame viisi, kuidas edastada kasutajatele värskendusi, kuid olgu see sise- või tehniline rakendus, kasutajatel peab olema võimalik tellida värskendusi (sealhulgas kiireid parandusi), kuid loobuda muudest. Lisaks peaks värskenduste kanal olema praegusest reageerivam. I isegi 6. mail olid veel kasutajad, kes ei olnud kasutanud ei parandust ega uut versiooni. Selle probleemiga on juba tegeletud, kuid see, mis juhtus, näitas, kui oluline see on.

Lõpuks vaatame üle lisa turvaarhitektuuri, et veenduda, et see tagab vajaliku turvalisuse taseme minimaalse riskiga midagi purustada.

Järgmisel nädalal vaatame põhjalikuma analüüsi tulemusi, aga seni olen valmis e-posti teel küsimustele vastama: ekr-blog@mozilla.com

Allikas: linux.org.ru