Noat oersetter: foar it gemak fan lêzers, datums wurde jûn yn Moskou tiid
Wy misten koartlyn it ferrinnen fan ien fan 'e sertifikaten dy't brûkt wurde om tafoegings te tekenjen. Dit resultearre yn tafoegings wurde útskeakele foar brûkers. No't it probleem foar it meastepart fêst is, wol ik de details diele fan wat der bard is en it wurk dat dien is.
Eftergrûn: tafoegings en hantekeningen
Ynstallearre tafoegings moatte hawwe Digitale hântekening, dy't brûkers beskermet tsjin kweade add-ons en fereasket minimale beoardieling fan add-ons troch Mozilla-meiwurkers. Wy yntrodusearre dizze eask yn 2015 omdat wy ûnderfine serieuze problemen mei kweade tafoegings.
Hoe it wurket: Elke kopy fan Firefox befettet in "root sertifikaat". De kaai foar dizze "root" wurdt opslein yn Hardware Security Module (HSM)sûnder netwurk tagong. Elke pear jier wurdt in nij "tuskensertifikaat" tekene mei dizze kaai, dy't brûkt wurdt by it ûndertekenjen fan add-ons. As in ûntwikkelder in add-on yntsjinnet, meitsje wy in tydlik "einsertifikaat" en tekenje it mei in tuskenlizzende sertifikaat. De add-on sels wurdt dan ûndertekene mei it definitive sertifikaat. Skematysk it liket sa.
Tink derom dat elk sertifikaat in "ûnderwerp" hat (oan wa't it sertifikaat is útjûn) en in "útjouwer" (dy't it sertifikaat hat útjûn). Yn it gefal fan in root-sertifikaat, "ûnderwerp" = "útjouwer", mar foar oare sertifikaten is de útjouwer fan it sertifikaat it ûnderwerp fan it âldersertifikaat wêrmei't it ûndertekene is.
In wichtich punt: elke tafoeging wurdt tekene troch in unyk einsertifikaat, mar hast altyd wurde dizze einsertifikaten tekene troch itselde tuskensertifikaat.
Notysje fan de skriuwer: De útsûndering is hiel âlde tafoegings. Yn dy tiid waarden ferskate tuskensertifikaten brûkt.
Dit tuskensertifikaat soarge foar problemen: elk sertifikaat is jildich foar in bepaalde perioade. Foar of nei dizze perioade is it sertifikaat ûnjildich en sil de browser gjin tafoegings brûke dy't ûndertekene binne troch dit sertifikaat. Spitigernôch ferrûn it tuskensertifikaat op 4 maaie om 4 oere.
De gefolgen ferskynden net fuortendaliks. Firefox kontrolearret de hantekeningen fan ynstalleare tafoegings net konstant, mar sawat ien kear elke 24 oeren, en de ferifikaasjetiid is yndividueel foar elke brûker. Dêrtroch krigen guon minsken fuortendaliks problemen, wylst oaren folle letter problemen ûnderfûnen. Wy waarden earst bewust fan it probleem om de tiid dat it sertifikaat ferrûn en begon fuortendaliks nei in oplossing te sykjen.
It ferminderjen fan skea
Sadree't wy realisearre wat der bard wie, besochten wy foar te kommen dat de situaasje slimmer waard.
Earst stopten se mei it akseptearjen en tekenjen fan nije oanfollingen. It hat gjin sin om in ferrûn sertifikaat foar dit te brûken. As ik weromsjoch soe ik sizze dat wy alles sa litte kinnen hawwe. Wy binne no opnij oannommen oanfollingen.
Twad, se stjoerde fuortendaliks in fix dy't foarkaam dat hantekeningen op deistige basis wurde kontrolearre. Sa hawwe wy dy brûkers bewarre waans browser de lêste XNUMX oeren noch gjin tiid hie om de tafoegings te kontrolearjen. Dizze reparaasje is no ynlutsen en is net mear nedich.
Parallel operaasje
Yn teory sjocht de oplossing foar it probleem ienfâldich: meitsje in nij jildich tuskenlizzende sertifikaat en tekenje elke tafoeging opnij. Spitigernôch sil dit net wurkje:
- wy kinne net fluch opnij tekenje 15 tûzen tafoegings tagelyk, it systeem is net ûntwurpen foar sa'n lading
- Nei't wy de tafoegings hawwe ûndertekene, moatte de bywurke ferzjes wurde levere oan brûkers. De measte tafoegings wurde ynstalleare fan Mozilla-tsjinners, dus Firefox sil updates fine binnen de kommende XNUMX oeren, mar guon ûntwikkelders distribuearje ûndertekene tafoegings fia kanalen fan tredden, sadat brûkers sokke tafoegings manuell moatte bywurkje
Ynstee dêrfan hawwe wy besocht in fix te ûntwikkeljen dy't alle brûkers soe berikke sûnder in protte of gjin aksje fan har kant te fereaskje.
Hiel fluch kamen wy by twa haadstrategyen, dy't wy parallel brûkten:
- Update Firefox om de jildigensperioade fan it sertifikaat te feroarjen. Dit sil besteande tafoegings wer op magyske wize wurkje, mar sil it útjaan en ferstjoeren fan in nije build fan Firefox fereaskje
- Generearje in jildich sertifikaat en oertsjûgje Firefox op ien of oare manier it te akseptearjen ynstee fan it besteande dat ferrûn is
Wy besletten om earst de earste opsje te brûken, dy't frij wurkber like. Oan 'e ein fan' e dei hawwe se in twadde fix útbrocht (in nij sertifikaat), wêr't wy letter oer prate.
It ferfangen fan in sertifikaat
Lykas ik hjirboppe neamde, wie it ferplicht:
- meitsje in nij jildich sertifikaat
- ynstallearje it op ôfstân yn Firefox
Om te begripen wêrom dit wurket, litte wy it add-on ferifikaasjeproses fan tichterby besjen. De tafoeging sels komt as in set fan bestannen, ynklusyf in keatling fan sertifikaten brûkt foar ûndertekening. Dêrtroch kin de tafoeging ferifiearre wurde as de browser it rootsertifikaat ken, dat ynboud is yn Firefox op 'e tiid fan it bouwen. Lykas wy al witte, is it tuskenlizzende sertifikaat lykwols ferrûn, dus it is ûnmooglik om de add-on te ferifiearjen.
As Firefox besiket in tafoeging te ferifiearjen, is it net beheind ta it brûken fan de sertifikaten yn de add-on sels. Ynstee dêrfan besiket de browser in jildige sertifikaatketen te meitsjen, begjinnend mei it einsertifikaat en trochgean oant it nei de root komt. Op it earste nivo begjinne wy mei it einsertifikaat en fine dan it sertifikaat wêrfan it ûnderwerp de útjouwer is fan it einsertifikaat (dat is it tuskensertifikaat). Typysk wurdt dit tuskenlizzende sertifikaat levere mei de add-on, mar elk sertifikaat fan de opslach fan 'e browser kin ek tsjinje as dit tuskenlizzende sertifikaat. As wy op ôfstân in nij jildich sertifikaat tafoegje kinne oan de sertifikaatwinkel, sil Firefox besykje it te brûken. De situaasje foar en nei it ynstallearjen fan in nij sertifikaat.
Nei it ynstallearjen fan it nije sertifikaat sil Firefox twa opsjes hawwe by it falidearjen fan de sertifikaatketen: brûk it âlde ûnjildige sertifikaat (dat sil net wurkje) of it nije jildige sertifikaat (dat sil wurkje). It is wichtich dat it nije sertifikaat deselde ûnderwerpnamme en iepenbiere kaai befettet as it âlde sertifikaat, sadat syn hantekening op it definitive sertifikaat jildich is. Firefox is tûk genôch om beide opsjes te besykjen oant it ien fynt dy't wurket, sadat de tafoegings wer testen wurde. Tink derom dat dit deselde logika is dy't wy brûke om TLS-sertifikaten te falidearjen.
Opmerking fan auteur: Lêzers dy't bekend binne mei WebPKI sille opmerke dat cross-sertifikaten op krekt deselde manier wurkje.
It geweldige ding oer dizze fix is dat it jo net fereasket om besteande tafoegings opnij te ûndertekenjen. Sadree't de browser it nije sertifikaat ûntfangt, sille alle tafoegings wer wurkje. De oerbleaune útdaging is om it nije sertifikaat te leverjen oan brûkers (automatysk en op ôfstân), en ek Firefox te krijen om útskeakele tafoegings opnij te kontrolearjen.
Normandje en it ûndersykssysteem
Iroanysk is dit probleem oplost troch in spesjale add-on neamd "systeem". Om ûndersyk út te fieren, hawwe wy in systeem ûntwikkele mei de namme Normandje dat ûndersyk leveret oan brûkers. Dizze stúdzjes wurde automatysk útfierd yn 'e browser, en hawwe ferbettere tagong ta de ynterne API's fan Firefox. Undersyk kin nije sertifikaten tafoegje oan 'e sertifikaatwinkel.
Notysje fan de skriuwer: Wy foegje gjin sertifikaat ta mei spesjale privileezjes; it is tekene troch it root-sertifikaat, dus Firefox fertrout it. Wy foegje it gewoan ta oan 'e pool fan sertifikaten dy't kin wurde brûkt troch de browser.
Dus de oplossing is om in stúdzje te meitsjen:
- it ynstallearjen fan it nije sertifikaat dat wy makke hawwe foar brûkers
- de blêder twinge om útskeakele tafoegings opnij te kontrolearjen sadat se wer wurkje
"Mar wachtsje," sizze jo, "add-ons wurkje net, hoe kin ik in systeem-add-on starte?" Litte wy it tekenje mei in nij sertifikaat!
Alles byinoar sette... wêrom duorret it sa lang?
Dat, it plan: jou in nij sertifikaat út om it âlde te ferfangen, meitsje in systeemtafoeging en ynstallearje it oan brûkers fia Normandje. De problemen, lykas ik sei, begon op 4 maaie om 4:00 oere, en al om 12:44 fan deselde dei, minder dan 9 oeren letter, hawwe wy in fix nei Normandje stjoerd. It duorre noch 6-12 oeren foar it berikken fan alle brûkers. Helemaal net min, mar minsken op Twitter freegje har ôf wêrom't wy net rapper hannelje koenen.
Earst duorre it tiid om in nij tuskensertifikaat út te jaan. Lykas ik hjirboppe neamde, wurdt de kaai foar it root-sertifikaat offline opslein yn 'e hardwarebefeiligingsmodule. Dit is goed út in feiligens eachpunt, sûnt de root wurdt brûkt hiel komselden en moat wurde betrouber beskerme, mar it is in bytsje ûngemaklik as jo moatte driuwend ûndertekenje in nij sertifikaat. Ien fan ús yngenieurs moast nei de HSM-opslach. Doe wiene d'r mislearre besykjen om it juste sertifikaat út te jaan, en elke poging koste ien of twa oeren te testen.
Twads naam de ûntwikkeling fan de systeem-add-on wat tiid. Konseptueel is it heul ienfâldich, mar sels ienfâldige programma's fereaskje soarch. Wy woene der wis fan wêze dat wy de situaasje net slimmer meitsje. Undersyk moat wurde hifke foardat se nei brûkers ferstjoerd wurde. Derneist moat de add-on ûndertekene wurde, mar ús add-on-ûndertekeningssysteem wie útskeakele, dus wy moasten in oplossing fine.
Uteinlik, doe't wy it ûndersyk klear hiene foar yntsjinjen, naam ynset tiid. De browser kontrolearret elke 6 oeren op Normandje-updates. Net alle kompjûters binne altyd oan en ferbûn mei it ynternet, dus it sil tiid duorje foar de fix te fersprieden nei brûkers.
Finale stappen
It ûndersyk soe it probleem foar de measte brûkers moatte reparearje, mar is net foar elkenien beskikber. Guon brûkers hawwe in spesjale oanpak nedich:
- brûkers dy't ûndersyk of telemetry hawwe útskeakele
- brûkers fan 'e Android-ferzje (Fennec), dêr't ûndersyk hielendal net stipe wurdt
- brûkers fan oanpaste builds fan Firefox ESR yn bedriuwen dêr't telemetry net ynskeakele wurde kin
- brûkers dy't efter MitM-proxy's sitte, om't ús add-on-ynstallaasjesysteem kaai pinning brûkt, wat net wurket mei sokke proxy's
- brûkers fan âldere ferzjes fan Firefox dy't gjin ûndersyk stypje
Wy kinne neat dwaan oan de lêste kategory brûkers - se moatte noch bywurkje nei de nije ferzje fan Firefox, om't ferâldere serieuze unpatched kwetsberens hawwe. Wy witte dat guon minsken op âldere ferzjes fan Firefox bliuwe om't se âlde tafoegings wolle útfiere, mar in protte fan 'e âlde tafoegings binne al oerdroegen nei nijere ferzjes fan 'e browser. Foar oare brûkers hawwe wy in patch ûntwikkele dy't in nij sertifikaat sil ynstallearje. It waard útbrocht as in bugfix-release (oersetternotysje: Firefox 66.0.5), sadat minsken it krije - nei alle gedachten al krigen - fia it reguliere updatekanaal. As jo in oanpaste build fan Firefox ESR brûke, nim dan kontakt op mei jo ûnderhâlder.
Wy begripe dat dit net ideaal is. Yn guon gefallen ferlearen brûkers add-ongegevens (bygelyks add-ongegevens Containers mei meardere akkounts).
Dizze side-effekt koe net foarkommen wurde, mar wy leauwe dat wy op koarte termyn de bêste oplossing foar de measte brûkers hawwe keazen. Op lange termyn sille wy sykje nei oare, mear avansearre arsjitektoanyske oanpakken.
Lessen
Earst die ús team in geweldige baan mei it meitsjen en ferstjoeren fan in oplossing yn minder dan 12 oeren neidat it probleem waard ûntdutsen. As ien dy't de gearkomsten bywenne kin, kin ik sizze dat yn dizze drege situaasje minsken heul hurd wurken en heul bytsje tiid fergriemd wie.
Fansels hie neat fan dit alles barre moatten. It is dúdlik de muoite wurdich om ús prosessen oan te passen om de kâns op sokke ynsidinten te ferminderjen en sanearjen makliker te meitsjen.
Takom wike sille wy in offisjele post-mortem publisearje en in list mei feroarings dy't wy fan doel binne oan te bringen. Foar no sil ik myn gedachten diele. Earst moat d'r in bettere manier wêze om de status te kontrolearjen fan wat in potinsjele tiidbom is. Wy moatte der wis fan wêze dat wy ússels net yn in situaasje fine wêr't ien fan har ynienen wurket. Wy binne noch oan it útwurkjen fan de details, mar op syn minst is it nedich om rekken te hâlden mei al sokke dingen.
Twadder hawwe wy in meganisme nedich om fluch updates oan brûkers te leverjen, sels as - foaral wannear - al it oare mislearret. It wie geweldich dat wy it "ûndersyk" systeem koenen brûke, mar it is in ûnfolslein ark en hat wat net winske side-effekten. Benammen wy witte dat in protte brûkers automatyske fernijings hawwe ynskeakele, mar wolle leaver net meidwaan oan ûndersyk (ik jou ta, ik haw se ek útskeakele!). Tagelyk hawwe wy in manier nedich om updates nei brûkers te stjoeren, mar wat de ynterne technyske ymplemintaasje ek is, brûkers moatte kinne abonnearje op updates (ynklusyf hot fixes) mar kieze foar al it oare. Derneist soe it updatekanaal mear responsyf wêze moatte dan it op it stuit is. Sels op 6 maaie wiene d'r noch brûkers dy't net profitearren fan sawol de fix as de nije ferzje. Oan dit probleem is al wurke, mar wat barde liet sjen hoe wichtich it is.
As lêste sille wy de befeiligingsarsjitektuer fan 'e add-on fan tichterby besjen om te soargjen dat it it juste nivo fan feiligens leveret mei minimaal risiko om wat te brekken.
Takom wike sille wy sjen nei de útkomsten fan in yngeande analyze fan wat der bard is, mar ik sil yntusken graach fragen beantwurdzje fia e-mail: [e-post beskerme]
Boarne: linux.org.ru