Notatka tłumacz: dla wygody czytelników daty podane są w czasie moskiewskim
Niedawno przeoczyliśmy datę wygaśnięcia jednego z certyfikatów używanych do podpisywania dodatków. Spowodowało to wyłączenie dodatków dla użytkowników. Teraz, gdy problem został w większości rozwiązany, chciałbym podzielić się szczegółami tego, co się wydarzyło i wykonanej pracy.
Tło: uzupełnienia i podpisy
Zainstalowane dodatki muszą mieć podpis cyfrowy, który chroni użytkowników przed złośliwymi dodatkami i wymaga minimalnego sprawdzania dodatków przez personel Mozilli. Wprowadziliśmy ten wymóg w 2015 roku, ponieważ tego doświadczyliśmy poważne problemy ze złośliwymi dodatkami.
Jak to działa: Każda kopia Firefoksa zawiera „certyfikat główny”. Klucz do tego „rootu” jest przechowywany w Sprzętowy moduł zabezpieczeń (HSM)bez dostępu do sieci. Tym kluczem, który jest używany podczas podpisywania dodatków, podpisywany jest co kilka lat nowy „certyfikat pośredni”. Kiedy programista przesyła dodatek, tworzymy tymczasowy „certyfikat końcowy” i podpisujemy go za pomocą certyfikatu pośredniego. Sam dodatek jest wówczas podpisywany końcowym certyfikatem. Schematycznie To wygląda tak.
Należy pamiętać, że każdy certyfikat posiada „podmiot” (dla którego certyfikat został wystawiony) oraz „wystawcę” (który wystawił certyfikat). W przypadku certyfikatu głównego „podmiot” = „wystawca”, ale w przypadku innych certyfikatów wystawcą certyfikatu jest podmiot certyfikatu nadrzędnego, którym jest on podpisany.
Ważna uwaga: każdy dodatek jest podpisany unikalnym certyfikatem końcowym, ale prawie zawsze te certyfikaty końcowe są podpisane tym samym certyfikatem pośrednim.
Nota autora: Wyjątkiem są bardzo stare dodatki. Stosowano wówczas różne certyfikaty pośrednie.
Ten pośredni certyfikat powodował problemy: każdy certyfikat jest ważny przez określony czas. Przed lub po tym okresie certyfikat jest nieważny i przeglądarka nie będzie korzystać z dodatków podpisanych tym certyfikatem. Niestety certyfikat pośredni stracił ważność 4 maja o godzinie 4 rano.
Konsekwencje nie pojawiły się od razu. Firefox nie sprawdza podpisów zainstalowanych dodatków stale, ale mniej więcej raz na 24 godziny, a czas weryfikacji jest indywidualny dla każdego użytkownika. W rezultacie u niektórych osób problemy wystąpiły natychmiast, u innych znacznie później. Po raz pierwszy dowiedzieliśmy się o problemie mniej więcej w momencie wygaśnięcia certyfikatu i natychmiast zaczęliśmy szukać rozwiązania.
Zmniejszanie obrażeń
Kiedy już zdaliśmy sobie sprawę, co się stało, próbowaliśmy zapobiec pogorszeniu się sytuacji.
Po pierwsze, przestali przyjmować i podpisywać nowe aneksy. Nie ma sensu używać do tego wygasłego certyfikatu. Patrząc wstecz, powiedziałbym, że mogliśmy zostawić wszystko tak, jak było. Obecnie wznowiliśmy przyjmowanie suplementów.
Po drugie, natychmiast wysłali poprawkę, która uniemożliwiała codzienne sprawdzanie podpisów. W ten sposób uratowaliśmy tych użytkowników, których przeglądarka nie zdążyła jeszcze sprawdzić dodatków w ciągu ostatnich XNUMX godzin. Ta poprawka została wycofana i nie jest już potrzebna.
Praca równoległa
Teoretycznie rozwiązanie problemu wygląda prosto: utwórz nowy ważny certyfikat pośredni i ponownie podpisz każdy dodatek. Niestety to nie zadziała:
- nie da się szybko przepisać 15 tysięcy dodatków na raz, system nie jest przystosowany do takiego obciążenia
- Po podpisaniu dodatków zaktualizowane wersje muszą zostać dostarczone użytkownikom. Większość dodatków instaluje się z serwerów Mozilli, więc Firefox znajdzie aktualizacje w ciągu najbliższych XNUMX godzin, ale niektórzy programiści rozpowszechniają podpisane dodatki za pośrednictwem kanałów stron trzecich, więc użytkownicy będą musieli ręcznie aktualizować takie dodatki
Zamiast tego próbowaliśmy opracować poprawkę, która dotrze do wszystkich użytkowników, nie wymagając od nich wielu działań lub żadnych działań.
Dość szybko doszliśmy do dwóch głównych strategii, które stosowaliśmy równolegle:
- Zaktualizuj przeglądarkę Firefox, aby zmienić okres ważności certyfikatu. Spowoduje to, że istniejące dodatki znów będą działać magicznie, ale będzie to wymagało wydania i dostarczenia nowej wersji Firefoksa
- Wygeneruj ważny certyfikat i w jakiś sposób przekonaj Firefoksa, aby go zaakceptował zamiast istniejącego, który wygasł
Zdecydowaliśmy się najpierw skorzystać z pierwszej opcji, która wydawała się całkiem wykonalna. Ostatecznie wypuścili drugą poprawkę (nowy certyfikat), o której porozmawiamy później.
Wymiana certyfikatu
Jak wspomniałem wyżej wymagane było:
- utwórz nowy ważny certyfikat
- zainstaluj go zdalnie w przeglądarce Firefox
Aby zrozumieć, dlaczego to działa, przyjrzyjmy się bliżej procesowi weryfikacji dodatku. Sam dodatek dostarczany jest w postaci zestawu plików zawierającego łańcuch certyfikatów używanych do podpisywania. W rezultacie dodatek można zweryfikować, jeśli przeglądarka zna certyfikat główny, który jest wbudowany w przeglądarkę Firefox w czasie kompilacji. Jednak jak już wiemy, certyfikat pośredni wygasł, więc nie ma możliwości weryfikacji dodatku.
Kiedy Firefox próbuje zweryfikować dodatek, nie ogranicza się to do użycia certyfikatów zawartych w samym dodatku. Zamiast tego przeglądarka próbuje utworzyć prawidłowy łańcuch certyfikatów, zaczynając od certyfikatu końcowego i kontynuując, aż dotrze do katalogu głównego. Na pierwszym poziomie zaczynamy od certyfikatu końcowego, a następnie znajdujemy certyfikat, którego podmiotem jest wystawca certyfikatu końcowego (czyli certyfikatu pośredniego). Zwykle ten certyfikat pośredni jest dostarczany z dodatkiem, ale dowolny certyfikat z pamięci przeglądarki może również służyć jako certyfikat pośredni. Jeśli uda nam się zdalnie dodać nowy ważny certyfikat do magazynu certyfikatów, Firefox spróbuje go użyć. Sytuacja przed i po zainstalowaniu nowego certyfikatu.
Po zainstalowaniu nowego certyfikatu Firefox będzie miał dwie możliwości sprawdzenia poprawności łańcucha certyfikatów: użyj starego, nieprawidłowego certyfikatu (który nie będzie działać) lub nowego ważnego certyfikatu (który będzie działać). Ważne jest, aby nowy certyfikat zawierał tę samą nazwę podmiotu i klucz publiczny co stary certyfikat, dzięki czemu jego podpis na certyfikacie końcowym będzie ważny. Firefox jest na tyle inteligentny, że wypróbowuje obie opcje, dopóki nie znajdzie tej, która działa, więc dodatki zostaną ponownie przetestowane. Należy pamiętać, że tej samej logiki używamy do sprawdzania poprawności certyfikatów TLS.
Nota autora: Czytelnicy zaznajomieni z WebPKI zauważą, że certyfikaty krzyżowe działają dokładnie w ten sam sposób.
Wspaniałą rzeczą w tej poprawce jest to, że nie wymaga ona ponownego podpisywania istniejących dodatków. Gdy tylko przeglądarka otrzyma nowy certyfikat, wszystkie dodatki zaczną ponownie działać. Pozostałym wyzwaniem jest dostarczenie użytkownikom nowego certyfikatu (automatycznie i zdalnie), a także nakłonienie Firefoksa do ponownego sprawdzenia wyłączonych dodatków.
Normandia i system badawczy
Jak na ironię, problem ten rozwiązuje specjalny dodatek o nazwie „system”. Aby przeprowadzić badania, opracowaliśmy system o nazwie Normandia, który dostarcza badania użytkownikom. Badania te są automatycznie przeprowadzane w przeglądarce i zapewniają lepszy dostęp do wewnętrznych interfejsów API przeglądarki Firefox. Badania mogą dodawać nowe certyfikaty do magazynu certyfikatów.
Komentarz autora: Nie dodajemy certyfikatu posiadającego jakieś specjalne uprawnienia; jest podpisany przez certyfikat główny, więc Firefox mu ufa. Po prostu dodajemy go do puli certyfikatów, z których może korzystać przeglądarka.
Rozwiązaniem jest więc utworzenie badania:
- instalując nowy certyfikat, który stworzyliśmy dla użytkowników
- zmuszając przeglądarkę do ponownego sprawdzenia wyłączonych dodatków, aby ponownie działały
„Ale czekaj” – mówisz – „dodatki nie działają. Jak mogę uruchomić dodatek systemowy?” Podpiszmy to nowym certyfikatem!
Składanie tego wszystkiego w całość... dlaczego to tak długo trwa?
A więc plan: wystawić nowy certyfikat w miejsce starego, stworzyć dodatek systemowy i zainstalować go użytkownikom przez Normandię. Problemy jak mówiłem zaczęły się 4 maja o godzinie 4:00 i już o godzinie 12:44 tego samego dnia, niecałe 9 godzin później wysłaliśmy fix do Normandii. Dotarcie do wszystkich użytkowników zajęło kolejne 6–12 godzin. Całkiem nieźle, ale ludzie na Twitterze pytają, dlaczego nie mogliśmy działać szybciej.
Po pierwsze, wydanie nowego certyfikatu pośredniego zajęło trochę czasu. Jak wspomniałem powyżej, klucz do certyfikatu głównego jest przechowywany offline w sprzętowym module bezpieczeństwa. Jest to dobre z punktu widzenia bezpieczeństwa, ponieważ root jest używany bardzo rzadko i powinien być niezawodnie chroniony, ale jest nieco niewygodny, gdy trzeba pilnie podpisać nowy certyfikat. Jeden z naszych inżynierów musiał udać się do magazynu HSM. Potem były nieudane próby wystawienia prawidłowego certyfikatu, a każda próba kosztowała jedną lub dwie godziny poświęcone na testowanie.
Po drugie, opracowanie dodatku do systemu zajęło trochę czasu. Koncepcyjnie jest to bardzo proste, ale nawet proste programy wymagają ostrożności. Chcieliśmy mieć pewność, że nie pogorszymy sytuacji. Badania należy przetestować przed wysłaniem do użytkowników. Ponadto dodatek musi zostać podpisany, ale nasz system podpisywania dodatków był wyłączony, więc musieliśmy znaleźć obejście.
Wreszcie, gdy badania były już gotowe do przesłania, wdrożenie zajęło trochę czasu. Przeglądarka sprawdza dostępność aktualizacji Normandii co 6 godzin. Nie wszystkie komputery są zawsze włączone i połączone z Internetem, dlatego rozpowszechnienie poprawki wśród użytkowników może zająć trochę czasu.
Ostatnie kroki
Badania powinny rozwiązać problem większości użytkowników, ale nie są dostępne dla wszystkich. Niektórzy użytkownicy wymagają specjalnego podejścia:
- użytkownicy, którzy wyłączyli badania lub telemetrię
- użytkownicy wersji na Androida (Fennec), gdzie badania nie są w ogóle obsługiwane
- użytkownicy niestandardowych wersji przeglądarki Firefox ESR w przedsiębiorstwach, w których nie można włączyć telemetrii
- użytkownicy siedzący za serwerami proxy MitM, ponieważ nasz system instalacji dodatków wykorzystuje przypinanie klucza, co nie działa z takimi serwerami proxy
- użytkownicy starszych wersji Firefoksa, które nie obsługują badań
W przypadku tej drugiej kategorii użytkowników nie możemy nic zrobić - powinni oni mimo to zaktualizować Firefoksa do nowej wersji, ponieważ te przestarzałe mają poważne, niezałatane luki w zabezpieczeniach. Wiemy, że niektórzy ludzie pozostają przy starszych wersjach przeglądarki Firefox, ponieważ chcą uruchamiać stare dodatki, ale wiele starych dodatków zostało już przeniesionych do nowszych wersji przeglądarki. Dla pozostałych użytkowników opracowaliśmy łatkę, która zainstaluje nowy certyfikat. Zostało wydane jako wydanie zawierające poprawki błędów (uwaga tłumacza: Firefox 66.0.5), więc ludzie dostaną ją – najprawdopodobniej już ją otrzymali – poprzez kanał regularnej aktualizacji. Jeśli używasz niestandardowej kompilacji przeglądarki Firefox ESR, skontaktuj się ze swoim opiekunem.
Rozumiemy, że nie jest to idealne rozwiązanie. W niektórych przypadkach użytkownicy utracili dane dodatkowe (na przykład dane dodatkowe Kontenery z wieloma kontami).
Tego efektu ubocznego nie dało się uniknąć, ale wierzymy, że w krótkiej perspektywie wybraliśmy najlepsze rozwiązanie dla większości użytkowników. W dłuższej perspektywie będziemy szukać innych, bardziej zaawansowanych podejść architektonicznych.
Lekcje
Po pierwsze, nasz zespół wykonał niesamowitą robotę, tworząc i wysyłając poprawkę w niecałe 12 godzin od wykrycia problemu. Jako osoba, która uczestniczyła w spotkaniach, mogę powiedzieć, że w tej trudnej sytuacji ludzie pracowali bardzo ciężko i zmarnowali bardzo mało czasu.
Oczywiście nic takiego nie powinno w ogóle mieć miejsca. Zdecydowanie warto dostosować nasze procesy, aby zmniejszyć prawdopodobieństwo wystąpienia takich incydentów i ułatwić ich naprawę.
W przyszłym tygodniu opublikujemy oficjalną sekcję zwłok i listę zmian, które zamierzamy wprowadzić. Na razie podzielę się swoimi przemyśleniami. Po pierwsze, musi istnieć lepszy sposób monitorowania stanu potencjalnej bomby zegarowej. Musimy mieć pewność, że nie znajdziemy się w sytuacji, w której któreś z nich nagle zacznie działać. Wciąż pracujemy nad szczegółami, ale przynajmniej trzeba to wszystko wziąć pod uwagę.
Po drugie, potrzebujemy mechanizmu szybkiego dostarczania aktualizacji użytkownikom, nawet gdy – zwłaszcza gdy – wszystko inne zawiedzie. Świetnie, że mogliśmy zastosować system „badawczy”, jest to jednak narzędzie niedoskonałe i niosące ze sobą pewne niepożądane skutki uboczne. W szczególności wiemy, że wielu użytkowników ma włączone automatyczne aktualizacje, ale wolałoby nie brać udziału w badaniach (przyznaję, ja też je mam wyłączone!). Jednocześnie potrzebujemy sposobu na wysyłanie aktualizacji do użytkowników, ale niezależnie od wewnętrznej implementacji technicznej użytkownicy powinni mieć możliwość subskrybowania aktualizacji (w tym poprawek), ale zrezygnować ze wszystkiego innego. Dodatkowo kanał aktualizacji powinien być bardziej responsywny niż obecnie. Nawet 6 maja nadal byli użytkownicy, którzy nie skorzystali ani z poprawki, ani z nowej wersji. Problem ten był już poruszany, ale to, co się wydarzyło, pokazało, jak bardzo jest on ważny.
Na koniec przyjrzymy się bliżej architekturze zabezpieczeń dodatku, aby upewnić się, że zapewnia on odpowiedni poziom bezpieczeństwa przy minimalnym ryzyku złamania czegokolwiek.
W przyszłym tygodniu przyjrzymy się wynikom dokładniejszej analizy tego, co się wydarzyło, ale w międzyczasie chętnie odpowiem na pytania drogą mailową: [email chroniony]
Źródło: linux.org.ru