Firma Mozilla o rozpoczęciu testowania w nocnych wersjach Firefoksa nowego mechanizmu identyfikacji unieważnionych certyfikatów — . CRLite umożliwia efektywne sprawdzanie unieważnienia certyfikatów na podstawie bazy danych przechowywanej w systemie użytkownika. Realizacja CRLite rozwijana przez Mozillę jest dostępna na licencji MPL 2.0. Kod do generowania bazy danych oraz komponenty serwerowe są napisane w i Go. Klientskie części dodane do Firefoksa do odczytu danych z bazy danych są napisane w języku Rust.
Dotychczasowa weryfikacja certyfikatów z wykorzystaniem zewnętrznych usług opartych na protokole (Online Certificate Status Protocol) wymaga gwarantowanego dostępu do sieci, co powoduje zauważalne opóźnienie w przetwarzaniu żądania (średnio 350 ms) i ma problemy z zapewnieniem prywatności (serwery OCSP odpowiadające na zapytania otrzymują informacje o konkretnych certyfikatach, co pozwala ocenić, jakie strony odwiedza użytkownik). Istnieje również możliwość lokalnej weryfikacji na podstawie list (Certificate Revocation List), ale wadą tej metody jest bardzo duży rozmiar pobieranych danych — obecnie baza danych unieważnionych certyfikatów zajmuje około 300 MB i jej rozwój trwa.
Aby zablokować skompromitowane i unieważnione certyfikaty wydawane przez centra certyfikacji, od 2015 roku w Firefoksie stosowany jest scentralizowany czarny wykaz w połączeniu z wykorzystaniem usługi do identyfikacji potencjalnej złośliwej aktywności. OneCRL, podobnie jak w Chrome, pełni rolę pośrednią, która agreguje listy CRL od centrów certyfikacji i zapewnia jednoczesną scentralizowaną usługę OCSP do sprawdzania unieważnionych certyfikatów, co pozwala na nie wysyłanie zapytań bezpośrednio do centrów certyfikacji. Mimo dużego wysiłku w poprawę niezawodności usługi sprawdzania certyfikatów online, dane telemetrii pokazują, że ponad 7% zapytań OCSP kończy się przekroczeniem czasu oczekiwania (kilka lat temu wskaźnik ten wynosił 15%).
Domyślnie, w przypadku braku możliwości weryfikacji przez OCSP, przeglądarka uznaje certyfikat za poprawny. Usługa może być niedostępna zarówno z powodu problemów sieciowych i ograniczeń w sieciach wewnętrznych, jak i z powodu blokowania przez atakujących — aby obejść weryfikację OCSP podczas ataku MITM, wystarczy po prostu zablokować dostęp do usługi weryfikacji. Częściowo w celu zapobieżenia podobnym atakom wdrożona została technika , która pozwala interpretować błąd w dostępie do OCSP lub niedostępność OCSP jako problem z certyfikatem, ale ta możliwość jest opcjonalna i wymaga specjalnego wydania certyfikatu.
CRLite pozwala zebrać pełne informacje o wszystkich odwołanych certyfikatach w łatwo aktualizowanej strukturze, o wielkości zaledwie 1 MB, co umożliwia przechowywanie pełnej bazy CRL po stronie klienta.
Przeglądarka będzie mogła codziennie synchronizować swoją kopię danych o odwołanych certyfikatach, a ta baza danych będzie dostępna w każdych warunkach.
CRLite łączy informacje z , publicznego dziennika wszystkich wydanych i odwołanych certyfikatów, oraz wyników skanowania certyfikatów w Internecie (zbierane są różne listy CRL instytucji certyfikujących i agregowane informacje o wszystkich znanych certyfikatach). Dane są pakowane z wykorzystaniem kaskadowych , probabilistycznej struktury, która dopuszcza fałszywe określenie braku elementu, ale wyklucza pominięcie istniejącego elementu (tzn. z pewnym prawdopodobieństwem może wystąpić fałszywe alarmowanie przy poprawnym certyfikacie, ale odwołane certyfikaty będą gwarantowanie wykrywane).
Aby wykluczyć fałszywe alarmy w CRLite, wprowadzono dodatkowe poziomy korekcyjne. Po wygenerowaniu struktury następuje przegląd wszystkich pierwotnych zapisów i identyfikacja występujących fałszywych alarmów. Na podstawie wyników tej kontroli tworzona jest dodatkowa struktura, która kaskadowo nakłada się na pierwszą i koryguje występujące fałszywe alarmy. Operacja ta jest powtarzana, aż fałszywe alarmy w kontroli nie zostaną całkowicie wykluczone. Zazwyczaj wystarcza stworzenie 7-10 warstw, aby pokryć wszystkie dane. Ponieważ stan bazy danych z powodu okresowej synchronizacji nieco opóźnia się w stosunku do aktualnego stanu CRL, kontrola nowych certyfikatów, wydanych po ostatniej aktualizacji bazy danych CRLite, odbywa się za pomocą protokołu OCSP, w tym przy użyciu techniki (zweryfikowana przez certyfikujący urząd odpowiedź OCSP jest przekazywana przez serwer obsługujący stronę podczas negocjacji połączenia TLS).
Dzięki filtrom Błuma, grudniowe zestawienie danych z WebPKI, obejmujące 100 milionów aktywnych certyfikatów i 750 tysięcy odwołanych certyfikatów, udało się skompresować do struktury o rozmiarze 1,3 MB. Proces generowania struktury jest dość zasobochłonny, ale jest realizowany na serwerze Mozilla, a użytkownik otrzymuje już gotową aktualizację. Na przykład w formie binarnej pierwotne dane używane do generacji wymagają około 16 GB pamięci podczas przechowywania w bazie danych Redis, a w postaci szesnastkowej zrzut wszystkich numerów seryjnych certyfikatów zajmuje około 6,7 GB. Proces agregowania wszystkich odwołanych i aktywnych certyfikatów zajmuje około 40 minut, a proces generowania skompresowanej struktury na podstawie filtru Błuma wymaga jeszcze 20 minut.
Obecnie Mozilla zapewnia aktualizację bazy danych CRLite cztery razy dziennie (nie wszystkie aktualizacje są dostarczane klientom). Generacja aktualizacji delta nie została jeszcze wdrożona — zastosowanie bsdiff4, używanego do tworzenia delta-aktualizacji wydań, nie zapewnia odpowiedniej efektywności dla CRLite, a aktualizacje okazują się nieuzasadnione duże. Aby wyeliminować ten problem, planuje się przemyślenie formatu struktury przechowywania, aby wykluczyć zbędne przebudowy i usuwanie warstw.
CRLite działa w Firefoxie w trybie pasywnym i jest używany równolegle z OCSP do gromadzenia statystyk na temat poprawności działania. CRLite można przełączyć na tryb głównego sprawdzania, w tym celu w about:config należy ustawić parametr security.pki.crlite_mode = 2.
Źródło: opennet.ru
