W przeszłości certyfikaty często traciły ważność, ponieważ trzeba je było odnawiać ręcznie. Ludzie po prostu o tym zapomnieli. Wraz z pojawieniem się Let's Encrypt i procedurą automatycznej aktualizacji wydaje się, że problem powinien zostać rozwiązany. Ale niedawno Historia Firefoksa pokazuje, że faktycznie jest to nadal aktualne. Niestety certyfikaty nadal tracą ważność.

Jeśli przegapiłeś tę historię, o północy 4 maja 2019 roku prawie wszystkie rozszerzenia Firefoksa nagle przestały działać.

Jak się okazało, do ogromnej awarii doszło wskutek tego, że Mozilla certyfikat wygasł, który służył do podpisywania rozszerzeń. Dlatego zostały one oznaczone jako „nieprawidłowe” i nie zostały zweryfikowane (szczegóły techniczne). Na forach jako obejście zalecano wyłączenie weryfikacji podpisu rozszerzenia w about: config lub zmianę zegara systemowego.

Mozilla szybko wypuściła łatkę do Firefoksa 66.0.4, która rozwiązuje problem z nieważnym certyfikatem, a wszystkie rozszerzenia wracają do normy. Twórcy zalecają jego zainstalowanie i nie używaj nie ma obejść pozwalających ominąć weryfikację podpisu, ponieważ mogą one kolidować z łatką.

Jednak ta historia po raz kolejny pokazuje, że wygaśnięcie certyfikatów pozostaje dziś palącym problemem.

W związku z tym interesujące jest przyjrzenie się dość oryginalnemu sposobowi, w jaki twórcy protokołu poradzili sobie z tym zadaniem DNSCrypt. Ich rozwiązanie można podzielić na dwie części. Po pierwsze, są to certyfikaty krótkoterminowe. Po drugie, ostrzeganie użytkowników o wygaśnięciu długoterminowych.

DNSCrypt

DNSCrypt to protokół szyfrowania ruchu DNS. Chroni komunikację DNS przed przechwyceniem i MiTM, a także pozwala ominąć blokowanie na poziomie zapytań DNS.

Protokół otacza ruch DNS pomiędzy klientem a serwerem w konstrukcji kryptograficznej, działającej poprzez protokoły transportowe UDP i TCP. Aby z niego skorzystać, zarówno klient, jak i narzędzie do rozpoznawania nazw DNS muszą obsługiwać DNSCrypt. Na przykład od marca 2016 r. jest ona włączona na jej serwerach DNS i w przeglądarce Yandex. Kilku innych dostawców również ogłosiło wsparcie, w tym Google i Cloudflare. Niestety nie ma ich zbyt wiele (na oficjalnej stronie znajdują się 152 publiczne serwery DNS). Ale program dnscrypt-proxy można zainstalować ręcznie na klientach z systemem Linux, Windows i MacOS. Istnieje również wdrożenia serwerowe.

Jak działa DNSCrypt? Krótko mówiąc, klient bierze klucz publiczny wybranego dostawcy i wykorzystuje go do weryfikacji jego certyfikatów. Krótkoterminowe klucze publiczne sesji i identyfikator zestawu szyfrów już tam są. Zachęcamy klientów do generowania nowego klucza dla każdego żądania, a serwery do zmiany kluczy co 24 godziny. Przy wymianie kluczy wykorzystywany jest algorytm X25519, do podpisywania - EdDSA, do szyfrowania blokowego - XSalsa20-Poly1305 lub XChaCha20-Poly1305.

Jeden z twórców protokołu Frank Denis пишетże automatyczna wymiana co 24 godziny rozwiązała problem wygasłych certyfikatów. Zasadniczo klient referencyjny dnscrypt-proxy akceptuje certyfikaty z dowolnym okresem ważności, ale wyświetla ostrzeżenie „Okres klucza dnscrypt-proxy dla tego serwera jest za długi”, jeśli jest on ważny dłużej niż 24 godziny. W tym samym czasie wypuszczono obraz Dockera, w którym zaimplementowano szybką zmianę kluczy (i certyfikatów).

Po pierwsze, jest to niezwykle przydatne ze względów bezpieczeństwa: jeśli serwer zostanie naruszony lub klucz wycieknie, wczorajszy ruch nie będzie mógł zostać odszyfrowany. Klucz już zmieniony. Będzie to prawdopodobnie stanowić problem dla wdrożenia ustawy Yarovaya, która zmusza dostawców do przechowywania całego ruchu, w tym ruchu zaszyfrowanego. Oznacza to, że w razie potrzeby można go później odszyfrować, prosząc o klucz ze strony. Ale w tym przypadku witryna po prostu nie może tego zapewnić, ponieważ używa kluczy krótkoterminowych, usuwając stare.

Ale co najważniejsze, pisze Denis, klucze krótkoterminowe zmuszają serwery do skonfigurowania automatyzacji od pierwszego dnia. Jeśli serwer połączy się z siecią, a skrypty zmiany klucza nie są skonfigurowane lub nie działają, zostanie to natychmiast wykryte.

Kiedy automatyzacja zmienia klucze co kilka lat, nie można na niej polegać, a ludzie mogą zapomnieć o wygaśnięciu certyfikatu. Jeśli będziesz zmieniać klucze codziennie, zostanie to natychmiast wykryte.

Jednocześnie, jeśli automatyka jest skonfigurowana normalnie, nie ma znaczenia, jak często zmieniane są klucze: co roku, co kwartał lub trzy razy dziennie. Jeśli wszystko będzie działać dłużej niż 24 godziny, będzie działać wiecznie, pisze Frank Denis. Według niego zalecenie codziennej rotacji kluczy w drugiej wersji protokołu wraz z gotowym obrazem Dockera, który to implementuje, skutecznie zmniejszyło liczbę serwerów z wygasłymi certyfikatami, jednocześnie poprawiając bezpieczeństwo.

Jednak niektórzy dostawcy nadal zdecydowali się, z powodów technicznych, na ustawienie okresu ważności certyfikatu na więcej niż 24 godziny. Problem ten został w dużej mierze rozwiązany za pomocą kilku linijek kodu w dnscrypt-proxy: użytkownicy otrzymują ostrzeżenie informacyjne na 30 dni przed wygaśnięciem certyfikatu, kolejną wiadomość o wyższym poziomie ważności na 7 dni przed wygaśnięciem oraz komunikat krytyczny, jeśli w certyfikacie pozostały jakiekolwiek pozostałości ważność krócej niż 24 godziny. Dotyczy to tylko certyfikatów, które początkowo mają długi okres ważności.

Wiadomości te dają użytkownikom możliwość powiadomienia operatorów DNS o zbliżającym się wygaśnięciu certyfikatu, zanim będzie za późno.

Być może gdyby wszyscy użytkownicy Firefoksa otrzymali taką wiadomość, to ktoś prawdopodobnie poinformowałby o tym programistów i nie dopuścili do wygaśnięcia certyfikatu. „Nie pamiętam ani jednego serwera DNSCrypt na liście publicznych serwerów DNS, któremu w ciągu ostatnich dwóch, trzech lat wygasł certyfikat” – pisze Frank Denis. W każdym razie prawdopodobnie lepiej najpierw ostrzec użytkowników, niż wyłączać rozszerzenia bez ostrzeżenia.

Źródło: www.habr.com