Poznámka překladatele: pro pohodlí čtenářů jsou data uvedena ve moskevském čase
Nedávno jsme propásli okamžik vypršení platnosti jednoho z certifikátů, které byly použity k podepisování doplňků. To vedlo k deaktivaci doplňků u uživatelů. Teď, když je většina problému opravena, bych chtěl sdílet detaily události a vykonanou práci.
Pozadí: doplňky a podpisy
Nainstalované doplňky musí mít digitální podpis, který chrání uživatele před škodlivými doplňky, a vyžaduje minimální kontrolu doplňků zaměstnanci Mozilly. Toto požadavek jsme zavedli v roce 2015, protože jsme čelili vážným problémům se škodlivými doplňky.
Jak to funguje: každá kopie Firefoxu obsahuje „kořenový certifikát“. Klíč k tomuto „kořeni“ je uložen v modulu hardwarové ochrany (HSM), který není připojen k síti. Každých několik let tímto klíčem podepisujeme nový „mezi certifikát“, který se používá při podepisování doplňků. Když vývojář odešle doplněk, vytvoříme dočasný „koncový certifikát“ a podepisujeme ho pomocí mezi certifikátu. Poté je samotný doplněk podepsán koncovým certifikátem. Schematicky to vypadá takto.
Všimněte si: každý certifikát má „subjekt“ (komu byl certifikát vydán) a „vydavatele“ (kdo certifikát vydal). V případě kořenového certifikátu je „subjekt“ = „vydavatel“, ale pro jiné certifikáty je vydavatelem certifikátu subjekt nadřazeného certifikátu, kterým byl podepsán.
Důležitý bod: každý doplněk je podepsán unikátním koncovým certifikátem, ale téměř vždy jsou tyto koncové certifikáty podepsány stejným mezi certifikátem.
Poznámka autora: výjimka se týká velmi starých doplňků. Tehdy se používaly různé mezi certifikáty.
Tento mezitímní certifikát způsobil problémy: každý certifikát je platný po určitou dobu. Před nebo po tomto období certifikát není platný a prohlížeč nebude používat rozšíření podepsaná tímto certifikátem. Bohužel, platnost mezitímního certifikátu vypršela 4. května v 4 hodiny ráno.
Následky se neprojevily hned. Firefox kontroluje podpisy nainstalovaných rozšíření nikoliv neustále, ale zhruba jednou za 24 hodin, přičemž čas kontroly je individuální pro každého uživatele. Výsledkem je, že někteří lidé čelili problémům okamžitě, jiní mnohem později. O problému jsme se dozvěděli poprvé přibližně v okamžiku, kdy vypršela platnost certifikátu, a okamžitě jsme začali hledat řešení.
Snižujeme škody
Jakmile jsme pochopili, co se stalo, pokusili jsme se zabránit zhoršení situace.
Za prvé, přestali jsme přijímat a podepisovat nová rozšíření. Není smysl používat k tomu prošlý certifikát. Když se ohlédnu zpět, řekl bych, že by možná bylo lepší nechat vše tak, jak to je. Nyní bylo přijímání rozšíření obnovené.
Za druhé, okamžitě jsme rozeslali opravu, která zabránila každodenní kontrole podpisů. Tímto jsme zachránili uživatele, u kterých prohlížeč v posledních 24 hodinách ještě nestihl zkontrolovat rozšíření. Tato oprava je nyní stažena, protože ji již není potřeba.
Paralelní provoz
Teoreticky vypadá řešení problému jednoduše: vytvořit nový platný mezitímní certifikát a podepsat každé rozšíření znovu. Bohužel, to nebude fungovat:
- nemůžeme rychle podepsat 15 tisíc rozšíření najednou, systém není na takovou zátěž připraven
- po podepsání rozšíření je nutné doručit aktualizované verze uživatelům. Většina rozšíření se instalována ze serverů Mozilla, takže Firefox najde aktualizace v následujících dnech, ale někteří vývojáři rozesílají podepsaná rozšíření prostřednictvím alternativních kanálů, a uživatelé by tak museli tyto rozšíření aktualizovat ručně
Místo toho jsme se pokusili vyvinout takovou opravu, která by dosáhla ke všem uživatelům, aniž by vyžadovala (nebo téměř nevyžadovala) jejich akce.
Poměrně rychle jsme se dostali k dvěma hlavním strategiím, které jsme používali současně:
- Aktualizovat Firefox, aby se změnila doba platnosti certifikátu. To způsobí, že stávající doplňky budou opět fungovat, ale bude vyžadovat vydání a dodání nové verze Firefoxu.
- Vytvořit platný certifikát a somehow přesvědčit Firefox, aby ho přijal místo stávajícího, jehož platnost vypršela.
Rozhodli jsme se nejprve použít první možnost, která se zdála být docela funkční. Na konci dne jsme vydali i druhé opravení (nový certifikát), o kterém si povíme později.
Výměna certifikátu
Jak jsem zmínil výše, bylo zapotřebí:
- vytvořit nový platný certifikát
- nainstalovat ho vzdáleně do Firefoxu
Abychom pochopili, proč to bude fungovat, podívejme se podrobněji na proces ověřování doplňku. Samotný doplněk se dodává jako souborový balíček, včetně řetězce certifikátů, které se používají k podepisování. V důsledku toho může být doplněk ověřen, pokud je prohlížeči znám kořenový certifikát, který je zabudován do Firefoxu během sestavení. Jak už víme, mezilehlý certifikát je však prošlý, takže ověření doplňku není možné.
Když se Firefox pokouší ověřit doplněk, neomezuje se pouze na používání certifikátů obsažených uvnitř samotného doplňku. Místo toho se prohlížeč pokusí vytvořit platný řetězec certifikátů, začínající konečným certifikátem, a pokračuje, dokud se nedostane k kořenu. Na první úrovni začínáme s konečným certifikátem a poté nalezneme certifikát, jehož subjekt je vydavatelem konečného certifikátu (tj. mezilehlý certifikát). Tento mezilehlý certifikát se obvykle dodává s doplňkem, ale může jím být také jakýkoli certifikát ze skladu prohlížeče. Pokud budeme moci vzdáleně přidat do skladu certifikátů nový platný certifikát, Firefox se ho pokusí použít. Situace před a po instalaci nového certifikátu.
Po nainstalování nového certifikátu bude mít Firefox dvě možnosti při kontrole řetězce certifikátů: použít starý neplatný certifikát (který nebude fungovat), nebo nový platný (který bude fungovat). Je důležité, že nový certifikát obsahuje stejné jméno subjektu a veřejný klíč jako starý certifikát, takže jeho podpis na koncovém certifikátu bude platný. Firefox je dost chytrý na to, aby zkusil obě možnosti, dokud nenajde tu funkční, takže doplňky budou opět ověřené. Všimněte si, že to je stejná logika, kterou používáme pro ověřování certifikátů TLS.
Poznámka autora: čtenáři obeznámení s WebPKI si všimnou, že přesně takto fungují křížové certifikáty.
Nejpozoruhodnější na tomto řešení je, že nevyžaduje pře podepsání stávajících doplňků. Jakmile prohlížeč obdrží nový certifikát, všechny doplňky opět začnou fungovat. Zůstává složitost s doručením nového certifikátu uživatelům (automaticky a vzdáleně), a také přesvědčit Firefox, aby znovu zkontroloval zakázané doplňky.
Normandy a systém výzkumu
Ironií je, že tento problém řeší speciální doplněk nazvaný "systémový". Abychom prováděli výzkum, vyvinuli jsme systém nazvaný Normandy, který doručuje výzkumy uživatelům. Tyto výzkumy se automaticky provádějí v prohlížeči a mají rozšířený přístup k interním API rozhraním Firefoxu. Výzkumy mohou přidávat nové certifikáty do úložiště certifikátů.
Poznámka autora: nepřidáváme certifikát s žádnými zvláštními privilegii; je podepsán kořenovým certifikátem, takže mu Firefox důvěřuje. Jen ho přidáváme do poolu certifikátů, které může prohlížeč použít.
Tedy řešení spočívá v tom, že vytváříme výzkum:
- který nainstaluje uživatelům námi vytvořený nový certifikát
- který přinutil prohlížeč znovu zkontrolovat zakázané doplňky, aby znovu fungovaly
"Ale počkej," řeknete, "doplňky přece nefungují, jak spustit systémový doplněk?" Podepíšeme ho novým certifikátem!
Skrýváme to vše dohromady… proč to trvá tak dlouho?
Takže plán: vydat nový certifikát na výměnu za starý, vytvořit systémový doplněk a nainstalovat ho uživatelům prostřednictvím Normandy. Problémy, jak jsem již zmínil, začaly 4. května v 4:00, a už v 12:44 téhož dne, méně než za 9 hodin, jsme poslali opravu do Normandy. Ještě dalších 6-12 hodin trvalo, než se dostala ke všem uživatelům. To už není špatné, ale uživatelé na Twitteru se ptají, proč jsme nemohli jednat rychleji.
Za prvé, trvalo to nějakou dobu, než byl vydán nový mezicertifikát. Jak jsem již zmínil výše, klíč k root certifikátu je uchováván offline v hardwarovém bezpečnostním modulu. To je dobré z hlediska bezpečnosti, protože root se používá velmi zřídka a měl by být dobře chráněn, ale je to poněkud nepohodlné, když je potřeba urgentně podepsat nový certifikát. Jeden z našich inženýrů musel jet do úložiště HSM. Poté následovaly neúspěšné pokusy o vydání správného certifikátu, a každý pokus stál jedno až dvě hodiny strávené testováním.
Za druhé, nějaký čas zabralo vývoj systémového doplňku. Koncepčně to je velmi jednoduché, ale i jednoduché programy vyžadují pozornost. Chtěli jsme se ujistit, že situaci nezhoršíme. Vědecký výzkum je třeba otestovat před odesláním uživatelům. Kromě toho musí být doplněk podepsán, ale náš systém pro podepisování doplňků byl vypnut, a museli jsme hledat alternativní cestu.
Nakonec, po přípravě výzkumu k odeslání, bylo potřeba nějaký čas na nasazení. Prohlížeč kontroluje aktualizace Normandy každých 6 hodin. Ne všechny počítače jsou neustále zapnuté a připojené k internetu, takže je třeba nějaký čas, než se oprava rozšíří mezi uživateli.
Konečné kroky
Výzkum by měl vyřešit problém u většiny uživatelů, ale není dostupný pro všechny. Někteří uživatelé vyžadují zvláštní přístup:
- uživatelé, kteří vypnuli výzkumy nebo telemetrii
- uživatelé Android verze (Fennec), kde výzkumy nejsou vůbec podporovány
- uživatelé vlastních sestavení Firefox ESR na firemních počítačích, kde není možné povolit telemetrii
- uživatelé, kteří používají proxy MitM, protože náš systém instalace doplňků používá vázání klíčů (key pinning), které nefunguje s takovými proxy
- uživatelé zastaralých verzí Firefoxu, které nepodporují výzkum
Nemáme co dělat s poslední kategorií uživatelů — ti by se měli určitě aktualizovat na novou verzi Firefoxu, protože zastaralé verze mají vážné neopravené zranitelnosti. Víme, že někteří lidé zůstávají na starých verzích Firefoxu, protože chtějí spouštět staré doplňky, ale mnoho starých doplňků již bylo přeportováno do novějších verzí prohlížeče. Pro ostatní uživatele jsme vyvinuli patch, který nainstaluje nový certifikát. Byl vydán jako oprava chyb (poznámka překladatele: Firefox 66.0.5), takže lidé jej dostanou — pravděpodobně již dostali — prostřednictvím běžného kanálu aktualizace. Pokud používáte vlastní sestavení Firefox ESR, obraťte se na svého správce.
Chápeme, že to všechno není ideální. V některých případech uživatelé ztratili data doplňků (například data doplňku Multi-Account Containers).
Tento vedlejší efekt se nepodařilo předejít, ale domníváme se, že jsme krátkodobě vybrali nejlepší řešení pro většinu uživatelů. V dlouhodobém horizontu budeme hledat další, sofistikovanější architektonické přístupy.
Lekce
Za prvé, náš tým odvedl úžasnou práci, když vytvořil a odeslal opravu za méně než 12 hodin po zjištění problému. Jako osoba, která byla přítomná na schůzích, mohu říct, že lidé v této obtížné situaci pracovali velmi tvrdě a málo času bylo ztraceno.
Očividně se to vůbec nemělo stát. Určitě je třeba upravit naše procesy, aby se snížila pravděpodobnost podobných incidentů a usnadnilo se napravování následků.
Příští týden publikujeme oficiální post-mortem a seznam změn, které plánujeme provést. Zatím se podělím o své myšlenky. Za prvé, měl by existovat lepší způsob, jak sledovat stav toho, co je potenciální časovaná bomba. Musíme si být jisti, že se nedostaneme do situace, kdy se jedna z nich náhle spustí. Ještě pracujeme na podrobnostech, ale minimálně je třeba provést evidenci všech těchto věcí.
Za druhé, potřebujeme mechanismus rychlého dodání aktualizací uživatelům, i když — zejména když — všechno ostatní nefunguje. Bylo skvělé, že jsme mohli použít systém „výzkumů“, ale to je nedokonalý nástroj a má některé nežádoucí vedlejší účinky. Konkrétně víme, že mnozí uživatelé mají zapnuté automatické aktualizace, ale raději by se nezúčastnili výzkumů (přiznávám, že je mám také vypnuté!). Zároveň potřebujeme způsob, jak zasílat aktualizace uživatelům, ale ať už je vnitřní technická realizace jakákoli, uživatelé by měli mít možnost se přihlásit k aktualizacím (včetně urgentních oprav), ale odmítnout všechno ostatní. Kromě toho by měl být kanál aktualizace rychlejší, než je tomu nyní. Ještě 6. května byli uživatelé, kteří nevyužili ani opravu, ani novou verzi. Tímto problémem jsme se již zabývali, ale události ukázaly, jak je to důležité.
Nakonec se zaměříme na architekturu bezpečnosti doplňků, abychom se ujistili, že poskytuje odpovídající úroveň zabezpečení s minimálním rizikem, že něco pokazíme.
Příští týden se podíváme na výsledky podrobnější analýzy toho, co se stalo, a zatím budu rád, když odpovím na otázky e-mailem: ekr-blog@mozilla.com
Zdroj: linux.org.ru
