Przyp. tłumacza: dla wygody czytelników daty podane są w czasie moskiewskim
Ostatnio przegapiliśmy moment wygaśnięcia jednego z certyfikatów używanych do podpisywania dodatków. Doprowadziło to do wyłączenia dodatków u użytkowników. Teraz, gdy w większości problem został rozwiązany, chciałbym opowiedzieć o szczegółach tego, co się wydarzyło, oraz o wykonanej pracy.
Kontekst: dodatki i podpisy
Zainstalowane dodatki muszą mieć cyfrowy podpis, który chroni użytkowników przed złośliwymi dodatkami i wymaga minimalnej weryfikacji dodatków przez pracowników Mozilli. Wprowadziliśmy ten wymóg w 2015 roku, ponieważ mieliśmy poważne problemy z złośliwymi dodatkami.
Jak to działa: każda kopia Firefox zawiera „certyfikat główny”. Klucz do tego „korzenia” jest przechowywany w module zabezpieczeń sprzętowych (HSM), który nie ma dostępu do sieci. Co kilka lat ten klucz podpisuje nowy „certyfikat pośredni”, który jest używany do podpisywania dodatków. Gdy deweloper przesyła dodatek, tworzymy tymczasowy „certyfikat końcowy” i podpisujemy go, używając certyfikatu pośredniego. Następnie certyfikat końcowy podpisuje sam dodatek. Schematycznie wygląda to tak.
Zauważ: każdy certyfikat ma „podmiot” (komu wydano certyfikat) i „wydawcę” (kto wydał certyfikat). W przypadku certyfikatu głównego „podmiot” = „wydawca”, ale dla innych certyfikatów wydawcą certyfikatu jest podmiot wyższego certyfikatu, który go podpisuje.
Ważna uwaga: każdy dodatek jest podpisany unikalnym certyfikatem końcowym, ale prawie zawsze te certyfikaty końcowe są podpisywane jednym i tym samym certyfikatem pośrednim.
Uwagi autora: wyjątek stanowią bardzo stare dodatki. W tym czasie używano różnych certyfikatów pośrednich.
Ten certyfikat pośredni spowodował problemy: każdy certyfikat jest ważny przez określony czas. Przed lub po tym okresie certyfikat jest nieważny, a przeglądarka nie użyje dodatków podpisanych tym certyfikatem. Niestety, ważność certyfikatu pośredniego wygasła 4 maja o 4:00.
Skutki nie były od razu widoczne. Firefox nie sprawdza podpisów zainstalowanych dodatków non-stop, lecz w przybliżeniu co 24 godziny, przy czym czas sprawdzania jest indywidualny dla każdego użytkownika. W rezultacie u niektórych osób problemy wystąpiły od razu, u innych znacznie później. Dowiedzieliśmy się o problemie w momencie, gdy wygasła ważność certyfikatu, i natychmiast zaczęliśmy szukać rozwiązania.
Minimalizujemy straty
Gdy tylko zrozumieliśmy, co się wydarzyło, postanowiliśmy zapobiec pogorszeniu sytuacji.
Po pierwsze, przestaliśmy akceptować i podpisywać nowe dodatki. Nie ma sensu używać do tego przestarzałego certyfikatu. Patrząc wstecz, powiedziałbym, że można było zostawić wszystko tak, jak jest. Teraz akceptacja dodatków została wznowiona.
Po drugie, natychmiast wysłaliśmy poprawkę, która zapobiegła codziennemu sprawdzaniu podpisów. Dzięki temu uratowaliśmy tych użytkowników, których przeglądarka w ciągu ostatniej doby jeszcze nie zdążyła sprawdzić dodatków. Ta poprawka została teraz wycofana, ponieważ nie ma już takiej potrzeby.
Praca równoległa
Teoretycznie, rozwiązanie problemu wydaje się proste: tworzymy nowy ważny certyfikat pośredni i ponownie podpisujemy każdy dodatek. Niestety, to nie zadziała:
- nie możemy szybko ponownie podpisać 15 tysięcy dodatków jednocześnie, system nie jest zaprojektowany na taką obciążenie
- po tym, jak podpiszemy dodatki, zaktualizowane wersje muszą dotrzeć do użytkowników. Większość dodatków jest instalowana z serwerów Mozilla, dlatego w ciągu najbliższych 24 godzin Firefox znajdzie aktualizacje, ale niektórzy deweloperzy dystrybuują podpisane dodatki za pośrednictwem nieoficjalnych kanałów, więc użytkownicy musieliby ręcznie zaktualizować takie dodatki
Zamiast tego staraliśmy się opracować poprawkę, która dotarłaby do wszystkich użytkowników, przy minimalnym (lub prawie żadnym) wymaganym udziale z ich strony.
Dość szybko doszliśmy do dwóch głównych strategii, które zastosowaliśmy równolegle:
- Zaktualizować Firefox, aby zmienić okres ważności certyfikatu. Sprawi to, że istniejące dodatki będą działać ponownie, ale będzie wymagać wydania i dostarczenia nowej wersji Firefox.
- Stworzyć ważny certyfikat i w jakiś sposób przekonać Firefox, aby zaakceptował go zamiast wygasłego.
Postanowiliśmy najpierw zastosować pierwszą opcję, która wydawała się całkiem skuteczna. Pod koniec dnia wydaliśmy drugą poprawkę (nowy certyfikat), o której porozmawiamy dalej.
Zamiana certyfikatu
Jak wspomniałem wcześniej, potrzebne było:
- stworzenie nowego ważnego certyfikatu
- zdalne zainstalowanie go w Firefox
Aby zrozumieć, dlaczego to zadziała, przyjrzyjmy się bliżej procesowi weryfikacji dodatku. Sam dodatek dostarczany jest w postaci zestawu plików, w tym łańcucha certyfikatów używanego do jego podpisania. W związku z tym dodatek może być zweryfikowany, jeśli przeglądarki znają certyfikat główny, który jest wbudowywany w Firefox podczas kompilacji. Jak już wiemy, certyfikat pośredni jest wygasły, więc weryfikacja dodatku jest niemożliwa.
Gdy Firefox próbuje zweryfikować dodatek, nie ogranicza się do użycia certyfikatów zawartych w samym dodatku. Zamiast tego, przeglądarka stara się zbudować ważny łańcuch certyfikatów, zaczynając od certyfikatu końcowego i kontynuuje, aż dotrze do korzenia. Na pierwszym poziomie zaczynamy od certyfikatu końcowego, a następnie znajdujemy certyfikat, którego podmiotem jest wydawca certyfikatu końcowego (to znaczy certyfikat pośredni). Zwykle ten certyfikat pośredni dostarczany jest wraz z dodatkiem, ale w tej roli może również występować każdy certyfikat z magazynu przeglądarki. Jeśli zdalnie dodamy do magazynu certyfikatów nowy ważny certyfikat, Firefox spróbuje go użyć. Sytuacja przed i po zainstalowaniu nowego certyfikatu.
Po zainstalowaniu nowego certyfikatu Firefox będzie miał dwie opcje przy weryfikacji łańcucha certyfikatów: korzystać ze starego, nieważnego certyfikatu (który nie będzie działał) lub nowego, ważnego (który będzie działał). Ważne jest, aby nowy certyfikat zawierał te same nazwisko podmiotu i klucz publiczny co stary certyfikat, dlatego jego podpis na końcowym certyfikacie będzie ważny. Firefox jest wystarczająco inteligentny, aby spróbować obu opcji, aż znajdzie działający, więc dodatki znowu będą uwierzytelnione. Zauważ, że to ta sama logika, której używamy do weryfikacji certyfikatów TLS.
Uwagi autora: czytelnicy zaznajomieni z WebPKI zauważą, że tak samo działają certyfikaty krzyżowe.
Najciekawsze w tej poprawce jest to, że nie wymaga ona ponownego podpisywania istniejących dodatków. Gdy tylko przeglądarka otrzyma nowy certyfikat, wszystkie dodatki znów będą działać. Pozostaje problem dostarczenia nowego certyfikatu użytkownikom (automatycznie i zdalnie) oraz zmuszenia Firefox do ponownej weryfikacji wyłączonych dodatków.
Normandy i system badań
Z ironią losu, ten problem rozwiązuje specjalny dodatek zwany «systemowym». Aby prowadzić badania, opracowaliśmy system o nazwie Normandy, który dostarcza badania użytkownikom. Badania te są automatycznie przeprowadzane w przeglądarce i mają rozszerzony dostęp do wewnętrznych interfejsów API Firefox. Badania mogą dodawać nowe certyfikaty do magazynu certyfikatów.
Uwagi autora: nie dodajemy certyfikatu z żadnymi specjalnymi przywilejami; jest on podpisany certyfikatem root, dlatego Firefox mu ufa. Po prostu dodajemy go do puli certyfikatów, które mogą być wykorzystywane przez przeglądarkę.
Tak więc rozwiązaniem jest stworzenie badania:
- instalującego nowo stworzony przez nas certyfikat u użytkowników
- zmuszającego przeglądarkę do ponownej weryfikacji wyłączonych dodatków, aby znowu zaczęły działać
„Ale poczekaj”, powiesz, „dodatki nie działają, jak uruchomić dodatek systemowy?”. Podpiszemy go nowym certyfikatem!
Zbierając wszystko razem… dlaczego to trwa tak długo?
Zatem plan: wydać nowy certyfikat w celu zastąpienia starego, stworzyć dodatek systemowy i zainstalować go u użytkowników za pomocą Normandy. Problemy, jak już mówiłem, zaczęły się 4 maja o 4:00, a już o 12:44 tego samego dnia, mniej niż 9 godzin później, wysłaliśmy poprawkę do Normandy. Zajęło to jeszcze 6-12 godzin, aby dotarło do wszystkich użytkowników. Już nieźle, ale użytkownicy na Twitterze pytają, dlaczego nie mogliśmy działać szybciej.
Po pierwsze, zajęło to czas, aby wydać nowy certyfikat pośredni. Jak już wspomniałem, klucz głównego certyfikatu jest przechowywany w trybie offline w module bezpieczeństwa sprzętowego. Jest to dobre z punktu widzenia bezpieczeństwa, ponieważ korzeń jest używany bardzo rzadko i powinien być dobrze chroniony, ale to trochę kłopotliwe, gdy trzeba nagle podpisać nowy certyfikat. Jeden z naszych inżynierów musiał pojechać do skarbca HSM. Następnie były nieudane próby wydania właściwego certyfikatu, a każda próba kosztowała jedno lub dwa godziny na testowanie.
Po drugie, stworzenie dodatku systemowego również zajęło pewien czas. Koncepcyjnie jest to bardzo proste, ale nawet proste programy wymagają uwagi. Chcieliśmy upewnić się, że nie pogorszymy sytuacji. Badanie musi zostać przetestowane przed wysłaniem do użytkowników. Poza tym dodatek musi być podpisany, ale nasz system podpisywania dodatków był wyłączony, więc musieliśmy szukać obejścia.
W końcu, po przygotowaniu badań do wysyłki, potrzebny był czas na wdrożenie. Przeglądarka sprawdza dostępność aktualizacji Normandy co 6 godzin. Nie wszystkie komputery są non-stop włączone i podłączone do internetu, więc potrzebny jest czas na to, żeby poprawka rozprzestrzeniła się wśród użytkowników.
Ostatnie kroki
Badanie powinno naprawić problem u większości użytkowników, ale nie jest dostępne dla wszystkich. Niektórzy użytkownicy wymagają specjalnego podejścia:
- użytkownicy, którzy wyłączyli badania lub telemetrię
- użytkownicy wersji Android (Fennec), gdzie badania nie są w ogóle wspierane
- użytkownicy niestandardowych wersji Firefox ESR w przedsiębiorstwach, gdzie nie można włączyć telemetrii
- Użytkownicy korzystający z proxy MitM, ponieważ nasz system instalacji dodatków wykorzystuje przypinanie kluczy (key pinning), które nie działa z takimi proxy.
- Użytkownicy przestarzałych wersji Firefox, które nie wspierają aktualizacji.
Nie możemy nic zrobić w przypadku ostatniej kategorii użytkowników — powinni oni zaktualizować się do nowej wersji Firefox, ponieważ przestarzałe wersje mają poważne, niezabezpieczone luki. Wiemy, że niektórzy pozostają przy starych wersjach Firefox, ponieważ chcą uruchamiać stare dodatki, ale wiele z nich zostało już przeniesionych do nowych wersji przeglądarki. Dla innych użytkowników opracowaliśmy łatkę, która zainstaluje nowy certyfikat. Została ona wydana jako poprawka błędów (uwaga tłumacza: Firefox 66.0.5), więc ludzie otrzymają ją — najprawdopodobniej już otrzymali — przez zwykły kanał aktualizacji. Jeśli używasz niestandardowej wersji Firefox ESR, skontaktuj się ze swoim konserwatorem.
Rozumiemy, że to wszystko nie jest idealne. W niektórych przypadkach użytkownicy tracili dane dodatków (na przykład dane dodatku Multi-Account Containers).
Tego skutku ubocznego nie udało się uniknąć, ale uważamy, że w krótkim okresie wybraliśmy najlepsze rozwiązanie dla większości użytkowników. W dłuższej perspektywie poszukamy innych, bardziej zaawansowanych podejść architektonicznych.
Lekcje
Przede wszystkim nasz zespół wykonał niesamowitą pracę, tworząc i wysyłając poprawkę w mniej niż 12 godzin od odkrycia problemu. Jako osoba, która uczestniczyła w spotkaniach, mogę powiedzieć, że w tej trudnej sytuacji ludzie pracowali bardzo ciężko i niewiele czasu zostało zmarnowane.
Oczywiście to wszystko w ogóle nie powinno się zdarzyć. Wyraźnie powinno się dostosować nasze procesy, aby zmniejszyć prawdopodobieństwo podobnych incydentów i ułatwić naprawę konsekwencji.
W przyszłym tygodniu opublikujemy oficjalny post-mortem oraz listę zmian, które zamierzamy wprowadzić. Na razie chciałbym podzielić się swoimi myślami. Po pierwsze, musi istnieć lepszy sposób na śledzenie stanu tego, co jest potencjalną bombą zegarową. Musimy mieć pewność, że nie znajdziemy się w sytuacji, w której jedna z nich nagle wybuchnie. Nadal pracujemy nad szczegółami, ale przynajmniej musimy prowadzić ewidencję wszystkich takich rzeczy.
Po drugie, potrzebujemy mechanizmu szybkiej dostawy aktualizacji do użytkowników, nawet wtedy, gdy – a szczególnie wtedy – wszystko inne nie działa. Było świetnie, że mogliśmy wykorzystać system „badań”, ale to niedoskonałe narzędzie i ma pewne niepożądane skutki uboczne. W szczególności wiemy, że wielu użytkowników ma włączoną automatyczną aktualizację, ale wolałoby nie uczestniczyć w badaniach (przyznam, że również mam je wyłączone!). Jednocześnie potrzebujemy sposobu na wysyłanie aktualizacji do użytkowników, ale bez względu na wewnętrzną realizację techniczną, użytkownicy powinni mieć możliwość subskrybowania aktualizacji (w tym szybkich poprawek), ale rezygnacji z wszystkiego innego. Ponadto kanał aktualizacji powinien być bardziej responsywny niż obecnie. Nawet 6 maja wciąż byli użytkownicy, którzy nie skorzystali ani z poprawki, ani z nowej wersji. Już nad tym problemem pracowaliśmy, ale to, co się wydarzyło, pokazało, jak jest on ważny.
Na koniec przyjrzymy się architekturze zabezpieczeń dodatków, aby upewnić się, że zapewnia należyty poziom bezpieczeństwa przy minimalnym ryzyku uszkodzenia czegoś.
W przyszłym tygodniu przeanalizujemy wyniki bardziej szczegółowej analizy wydarzeń, a na razie chętnie odpowiem na pytania drogą mailową: ekr-blog@mozilla.com
Źródło: linux.org.ru
