Hiljuti toimunud täiendusete tehnilised detailid Firefoxis

Tõlkija märkus: lugejate mugavuse huvides on kuupäevad esitatud Moskva ajavööndis

Hiljuti jäime ilma ühe meie allkirjastamiseks kasutatava sertifikaadi kehtivusajast. See põhjustas täiendusete peatamise kasutajate seas. Nüüd, kui enamik probleeme on lahendatud, soovin rääkida toimunust lähemalt ning tehtud tööst.

Taust: täiendid ja allkirjad

Kuigi paljud inimesed kasutavad brauserit "karbist välja", toetab Firefox laiendusi, mida nimetatakse "täiendused". Nende abil saavad kasutajad lisada brauserisse erinevaid funktsioone. Praegu on saadaval üle 15 000 täiendi: alates reklaami blokeerimisest kuni sajate vahelehtede haldamiseni.

Paigaldatud täiendusidel peab olema digitaalne allkiri, mis kaitseb kasutajaid pahatahtlike täienduste eest ning nõuab minimaalset täienduste kontrollimist Mozilla töötajate poolt. Meie kehtestasime selle nõude 2015. aastal, kuna kogesime tõsiseid probleeme pahatahtlike täiendustega.

Kuidas see töötab: iga Firefoxi koopia sisaldab "juursertifikaati". Selle "juure" võtme hoiab riistvara kaitsemoodul (HSM), mis ei ole võrku ühendatud. Iga paariaasta tagant allkirjastatakse selle võtmega uus "vahesertifikaat", mida kasutatakse lisade allkirjastamiseks. Kui arendaja saadab lisa, loome ajutise "lõppsertifikaadi" ja allkirjastame selle vahesertifikaadiga. Seejärel allkirjastatakse lõppsertifikaadiga ise lisa. Skeemiliselt näeb see välja nii.

Pange tähele: igal sertifikaadil on "subjekt" (kellele sertifikaat on välja antud) ja "väljaandja" (kes sertifikaadi väljastas). Juursertifikaadi puhul on "subjekt" = "väljaandja", kuid muude sertifikaatide puhul on sertifikaadi väljaandja ettepoole mineva sertifikaadi subjekt, millega see on allkirjastatud.

Oluline punkt: iga lisa on allkirjastatud unikaalse lõppsertifikaadiga, kuid peaaegu alati on need lõppsertifikaadid allkirjastatud sama vahesertifikaadiga.

Autori märkused: erandiks on väga vanad lisandused. Sel ajal kasutati erinevaid vahesertifikaate.

See vahesertifikaat tekitas probleeme: iga sertifikaat on kehtiv kindla perioodi jooksul. Enne või pärast seda perioodi sertifikaat ei kehti ja brauser ei kasuta selle sertifikaadiga allkirjastatud lisandeid. Kahjuks aegus vahesertifikaadi kehtivus 4. mail kell 4 hommikul.

Tagajärjed ei ilmunud kohe. Firefox kontrollib installitud lisandite allkirju mitte pidevalt, vaid umbes kord 24 tunni jooksul, ning kontrollimise aeg on individuaalne iga kasutaja jaoks. Selle tulemusena tekkisid probleemid mõnel inimesel kohe, mõnel aga palju hiljem. Saime probleemist teada umbes samal ajal, kui sertifikaadi kehtivus lõppes, ja hakkasime kohe lahendust otsima.

Kahju vähendamine

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

Esiteks lõpetati uute lisade vastuvõtmine ja allkirjastamine. Pole mõtet kasutada selleks aegunud sertifikaati. Tagasi vaadates ütleksin, et oleks võinud kõik nii jätta. Praegu on lisade vastuvõtt taas alustatud.

Teiseks saadeti kohe välja parandav teade, mis takistas igapäevaseid allkirjade kontrollimisi. Nii päästsime neid kasutajaid, kelle brauserid ei olnud viimase 24 tunni jooksul veel lisanud kontrollinud. Praegu on see parandav teade tagasi võetud, vajadus selle järele on kadunud.

Paralleelne töö

Teoreetiliselt näeb probleemi lahendus välja lihtne: loome uue kehtiva vahe-sertifikaadi ja uuesti allkirjastame iga lisa. Kahjuks see ei õnnestu:

• me ei saa kiiresti allkirjastada 15 tuhat lisandust korraga, süsteem ei ole selliseks koormuseks valmis.
• Pärast lisade allkirjastamist peavad värskendatud versioonid jõudma kasutajateni. Enamik lisasid installitakse Mozilla serveritest, seega leiab Firefox järgmise 24 tunni jooksul värskendusi, kuid mõned arendajad levitavad allkirjastatud lisasid kolmandate osapoolte kanalite kaudu, mistõttu peavad kasutajad selliseid lisasid käsitsi värskendama.

Selle asemel püüdsime välja töötada lahenduse, mis jõuaks kõigi kasutajateni, nõudmata (või peaaegu mitte nõudmata) nende poolset tegevust.

Jõudsime üsna kiiresti kahe peamise strateegiani, mida kasutasime paralleelselt:

• Värskendada Firefoxi, et muuta sertifikaadi kehtivusaega. See paneks olemasolevad lisad taas töötama, kuid nõuaks uue Firefoxi versiooni väljaandmist ja tarnimist.
• Luua kehtiv sertifikaat ja kuidagi veenda Firefoxi seda aktsepteerima, mitte olemasolevat, mille kehtivusaeg on lõppenud.

Otsustasime alguses kasutada esimest varianti, mis tundus üsna töökindel. Päeva lõpuks vabastasime ka teise lahenduse (uue sertifikaadi), millest räägime edasi.

Sertifikaadi vahetamine

Nagu ma eelnevalt mainisin, oli vajalik:

• luua uus kehtiv sertifikaat
• kaugelt see Firefoxi installida

Selle mõistmiseks, miks see töötab, vaatame põhjalikumalt pistikprogrammi kontrollimise protsessi. Ise pistikprogramm koosneb failide kogumist, sealhulgas sertifikaadivõrgustikku, mida kasutatakse allkirjastamiseks. Seetõttu saab pistikprogrammi kontrollida, kui brauserile on teada juursertifikaat, mis on Firefoxi koostamise ajal sisse ehitatud. Kuid nagu me juba teame, on vahe-sertifikaat aegunud, seetõttu ei ole pistikprogrammi kontrollimine võimalik.

Kui Firefox üritab laiendust kontrollida, ei piira ta end ainult laienduses sisalduvate sertifikaatide kasutamisega. Selle asemel püüab brauser luua kehtiva sertifikaadi ahela, alustades lõppsertifikaadist ja liikudes edasi kuni juureni. Esimesel tasemel alustame lõppsertifikaadist ja seejärel otsime sertifikaadi, mille subjekt on lõppsertifikaadi väljaandja (st vahesertifikaat). Tavalises olukorras kaasneb see vahesertifikaat laiendusega, kuid sellessamas rollis võidakse kasutada ka mõnda sertifikaati brauseri hoidlast. Kui suudame kaugel lisada sertifikaatide hoidlasse uue kehtiva sertifikaadi, püüab Firefox seda kasutada. Olukord enne ja pärast uue sertifikaadi installimist.

Pärast uue sertifikaadi installimist on Firefoxil sertifikaadiga seotud kaheksa võimalust: kasutada vanemat ja kehtetuks tunnistatud sertifikaati (mis ei tööta) või uut ja kehtivat sertifikaati (mis töötab). Oluline on, et uus sertifikaat sisaldab samu subjektinime ja avalikku võtme, mis ka vanal sertifikaadil, seega on selle allkiri lõppsertifikaadil kehtiv. Firefox on piisavalt nutikas, et proovida mõlemat varianti, kuni ta leiab töötava, seetõttu saavad lisad taas kinnitatud. Pange tähele, et see on sama loogika, mida me kasutame TLS-sertifikaatide kontrollimisel.

Autori märkus: lugejad, kes tunnevad WebPKI-d, märkavad, et ristsertifikaadid töötavad täpselt samamoodi.

Selle paranduse kõige rohkem tähelepanuväärne aspekt on see, et see ei nõua olemasolevate lisade allkirjastamist. Niipea kui brauser saab uue sertifikaadi, hakkavad kõik lisad taas tööle. Üks keerukus seisneb selles, kuidas tarnida uus sertifikaat kasutajatele (automaatselt ja eemalt) ning sundida Firefoxi läbi vaatama keelatud lisasid.

Normandy ja uurimisüsteem

Ironiseerivalt lahendab selle probleemi spetsiaalne lisand, mida nimetatakse 'süsteemseks'. Uuringute läbiviimiseks oleme arendanud süsteemi nimega Normandy, mis toob uuringud kasutajateni. Need uuringud toimuvad automaatselt brauseris ja neil on laiendatud juurdepääs Firefoxi sise-API-dele. Uuringud saavad lisada uusi sertifikaate sertifikaatide salvestusse.

Autori märkuse kohaselt: me ei lisa sertifikaati mingite eriliste privileegidega; see on allkirjastatud juursertifikaadiga, seetõttu usaldab Firefox seda. Me lihtsalt lisame selle sertifikaatide hulka, mida brauser saab kasutada.

Seega, lahendus seisneb uuringu loomises:

• kasutajatele meie loodud uue sertifikaadi seadmine
• brauseri sundimine desaktiveeritud lisandeid uuesti kontrollima, et need töötaksid taas

„Aga oota,“ ütlete teie, „lisandid ei tööta, kuidas käivitada süsteemset lisandit?“. Allkirjastame selle uue sertifikaadiga!

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

Nii et, plaan: välja anda uus sertifikaat, et asendada vana, luua süsteemne täiendus ja paigaldada see kasutajatele läbi Normandy. Probleemid, nagu ma ütlesin, algasid 4. mail kell 4:00 ja juba kell 12:44 samal päeval, vähem kui 9 tunni jooksul, saatsime paranduse Normandy'sse. Selle jõudmine kõikide kasutajateni võttis veel 6-12 tundi. See on juba mitte halb, kuid Twitteris küsivad kasutajad, miks me ei saanud kiiremini tegutseda.

Esiteks, uue vahesertifikaadi väljaandmiseks kulus aega. Nagu ma eelnevalt mainisin, on juursertifikaadi võti salvestatud eraldi turvaseadmestikku. See on turvalisuse seisukohalt hea, kuna juurt kasutatakse väga harva ja see peab olema usaldusväärselt kaitstud, kuid see on veidi ebamugav, kui on vaja kiiresti uue sertifikaadi allkirjastamist. Ühel meie inseneridest tuli minna HSM-i ladustamisse. Seejärel olid katsetused õigete sertifikaatide väljastamiseks ebaõnnestunud, ning iga katse võttis aega üks kuni kaks tundi, mis kulus testimise peale.

Teiseks, võttis süsteemi täienduse väljatöötamine aega. Kontseptuaalselt on see väga lihtne, kuid isegi lihtsad programmid nõuavad tähelepanu. Soovisime veenduda, et me ei teeks olukorda veel hullemaks. Uuringut peab enne kasutajatele saatmist testima. Lisaks peab täiendus olema allkirjastatud, kuid meie täiendite allkirjastamise süsteem oli välja lülitatud, seega tuli leida lahendus.

Lõpuks, kui olime uuringud saatmiseks ette valmistanud, võttis juurutamine aega. Brauser kontrollib Normandy värskenduste kättesaadavust iga 6 tunni järel. Mitte kõik arvutid ei ole pidevalt sisse lülitatud ja võrguga ühendatud, seetõttu on vajalik aeg, et parandus kasutajateni jõuaks.

Lõppfaasid

Uuring peaks lahendama probleemi enamikul kasutajatel, kuid see ei ole kõigile kergesti kättesaadav. Teatud kasutajate puhul on vajalik eriline lähenemine:

• kasutajad, kes on uuringud või telemetria välja lülitanud
• Androidi versiooni (Fennec) kasutajad, kus uuringud pole üldse toetatud
• Firefox ESR kohandatud versioonide kasutajad ettevõtetes, kus telemeetriat ei ole võimalik lubada
• kasutajad, kes on MitM-prokside taga, kuna meie lisade paigaldamise süsteem kasutab võtme sidumist, mis ei tööta selliste proksidega
• vanemate Firefoxi versioonide kasutajad, mis ei toeta uuringute läbiviimist

Me ei saa viimase kategooria kasutajatega midagi ette võtta — nad peaksid kindlasti uuendama Firefoxi uue versioonini, sest vanematel on tõsised, lahendamata haavatavused. Me teame, et mõned inimesed jäävad vanadele Firefoxi versioonidele lootuses käivitada vanu lisaelemente, kuid paljusid vanu lisaelemente on juba kohandatud uute brauseriversioonide jaoks. Ülejäänud kasutajatele oleme välja töötanud patareid, mis paigaldavad uue sertifikaadi. See on välja antud kui veaparanduse versioon (tõlkija märkus: Firefox 66.0.5), seega saavad inimesed selle — tõenäoliselt on nad juba saanud — läbi tavalise uuenduste kanali. Kui kasutate kohandatud Firefox ESR versiooni, pöörduge oma hooldaja poole.

Me mõistame, et see pole kõikehõlmav lahendus. Mõnel juhul on kasutajad kaotanud lisaandmed (näiteks lisasegu Multi-Account Containers).

Seda kõrvalmõju oli vältimatu, kuid usume, et lühiajaliselt valisime enamikule kasutajatele parima lahenduse. Pikaajalises plaanis otsime välja teisi, täiustatud arhitektuurilisi lähenemisviise.

Tunnid

Esiteks on meie meeskond teinud imelist tööd, luues ja edastades paranduse vähem kui 12 tunni jooksul pärast probleemi tuvastamist. Inimesena, kes oli koosolekutel kohal, võin öelda, et selles keerulises olukorras töötasid inimesed väga hoolsalt ning aega raisati vaid vähe.

On ilmne, et seda kõike ei oleks tohtinud üldse juhtuda. Selgelt on vaja korrigeerida meie protsesse, et vähendada sarnaste juhtumite tõenäosust ja kergendada tagajärgede eemaldamist.

Järgmise nädala jooksul avaldame ametliku post-mortemi ja muudatuste nimekirja, mida kavatseme teha. Kuni selle ajani jagan oma mõtteid. Esiteks peab olema parem viis jälgida, mis on potentsiaalne aegpomm. Peame olema kindlad, et me ei satuks olukorda, kus üks neist ühel hetkel plahvatab. Töötame veel üksikasjade kallal, kuid vähemalt on vajalik kõigi selliste asjade arvestamine.

Teiseks vajame kiire uuenduste edastamise mehhanismi kasutajatele, isegi siis, kui — eriti kui — kõik muu ei tööta. Oli suurepärane, et saime kasutada „uurimiste“ süsteemi, kuid see on ebatäiuslik tööriist ja sel on mõned soovimatud kõrvaltoimed. Eelkõige teame, et paljude kasutajate automaatne värskendamine on sisse lülitatud, kuid nad eelistaksid uurimistest mitte osa võtta (tõden, et mul on need samuti välja lülitatud!). Samas vajame viisi, kuidas edastada kasutajatele värskendusi, kuid ükskõik, milline on sisemine tehniline teostus, peavad kasutajad saama tellida värskendusi (sealhulgas kiireid parandusi), kuid loobuda kõigest muust. Lisaks peab värskenduste kanal olema praegusest reageerivam. Isegi 6. mail olid kasutajad, kes ei olnud kasutanud ühtki parandust ega uut versiooni. Selle probleemi kallal on juba töötatud, kuid toimunud näitas, kui oluline see on.

Lõpuks vaatame lähemalt lisaehitiste turbekonstruktsiooni, et veenduda, et see tagab vajaliku turvalisuse taseme minimaalse riskiga midagi rikkuda.

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

Allikas: linux.org.ru