Wcześniej certyfikaty często wygasały, ponieważ trzeba je było odnawiać ręcznie. Ludzie po prostu o tym zapominali. Pojawienie się Let’s Encrypt i automatycznej procedury aktualizacji miało rozwiązać ten problem. Jednak niedawna pokazuje, że problem wciąż istnieje. Niestety, certyfikaty nadal wygasają.
Jeśli ktoś przegapił tę historię, w północ 4 maja 2019 roku nagle przestały działać niemal wszystkie rozszerzenia Firefoxa.
Jak się okazało, masowa awaria miała miejsce z powodu wymagalności certyfikatu szczegóły technicznelub zmianę ustawienia zegara w systemie. about:config Mozilla szybko wydała poprawkę Firefox 66.0.4, która rozwiązuje problem z nieważnym certyfikatem, a wszystkie rozszerzenia wracają do normalności. Programiści zalecają zainstalowanie tej poprawki i
nie korzystanie z Niemniej jednak, ta historia jeszcze raz pokazuje, że wygaszenie certyfikatów pozostaje aktualnym problemem także dzisiaj.
W związku z tym warto spojrzeć na dość oryginalny sposób, w jaki problem ten rozwiązali twórcy protokołu
DNSCrypt DNSCrypt to protokół szyfrujący ruchu DNS. Chroni komunikację DNS przed przechwyceniem i atakami typu MiTM, a także umożliwia obejście blokad na poziomie zapytań DNS.
. 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 certyfikatów długoterminowych.
Protokół kapsułkuje ruch DNS między klientem a serwerem w konstrukcję kryptograficzną, korzystając z protokołów transportowych UDP i TCP. Aby go używać, zarówno klient, jak i resolver DNS muszą wspierać DNSCrypt. Na przykład od marca 2016 roku wprowadził go na swoich serwerach DNS oraz w przeglądarkach „Yandex”. Wsparcie ogłosili także inni dostawcy, w tym Google i Cloudflare. Niestety, nie jest ich zbyt wielu (na oficjalnej stronie wymieniono 152 publiczne serwery DNS). Ale program
dnscrypt-proxy można zainstalować ręcznie na klientach działających na Linuxie, Windowsie i MacOS. Istnieją też .
Jak działa DNSCrypt? Krótko mówiąc, klient bierze publiczny klucz wybranego dostawcy i za jego pomocą weryfikuje jego certyfikaty. Znajdują się tam krótkoterminowe publiczne klucze do sesji oraz identyfikator zestawu szyfrów. Klientom zaleca się generowanie nowego klucza dla każdego zapytania, a serwerom – zmianę kluczy co 24 godziny. Przy wymianie kluczy stosuje się algorytm X25519, do podpisu – EdDSA, do szyfrowania blokowego – XSalsa20-Poly1305 lub XChaCha20-Poly1305.
Jednym z twórców protokołu jest Frank Denis , który stwierdził, że automatyczna zmiana co 24 godziny rozwiązała problem przestarzałych certyfikatów. W zasadzie, referencyjny klient dnscrypt-proxy akceptuje certyfikaty o dowolnym czasie ważności, ale wyświetla ostrzeżenie "Okres ważności kluczy dnscrypt-proxy dla tego serwera jest zbyt długi", jeśli jest ważny dłużej niż 24 godziny. Jednocześnie wydano obraz Docker, w którym zaimplementowano szybką zmianę kluczy (i certyfikatów).
Po pierwsze, jest to niezwykle przydatne dla bezpieczeństwa: jeśli serwer zostanie skompromitowany lub klucz wyciekł, to wczorajszy ruch nie może być odszyfrowany. Klucz już się zmienił. Może to stanowić problem dla realizacji "ustawy Jarowej", która zmusza dostawców do przechowywania całego ruchu, w tym szyfrowanego. Zakłada się, że później można go będzie odszyfrować w razie potrzeby, żądając klucza od strony. Ale w tym przypadku strona po prostu nie będzie mogła go dostarczyć, ponieważ używa krótkoterminowych kluczy, usuwając stare.
Ale głównym zdaniem, pisze Denis, krótkoterminowe klucze zmuszają serwery od pierwszego dnia do skonfigurowania automatyzacji. Jeśli serwer łączy się z siecią, a skrypty zmiany kluczy nie są skonfigurowane lub nie działają, to zostanie to natychmiast wykryte.
Kiedy automatyzacja zmienia klucze co kilka lat, nie można na niej polegać, a ludzie mogą zapomnieć o upływie terminu ważności certyfikatu. Przy codziennej zmianie kluczy będzie to wykryte natychmiast.
Jednakże, jeśli automatyzacja jest prawidłowo skonfigurowana, to nie ma znaczenia, jak często zmienia się klucze: co roku, co kwartał lub trzy razy dziennie. Jeśli wszystko działa przez ponad 24 godziny, to będzie działać wiecznie, pisze Frank Denis. Jego zdaniem, zalecenie codziennej zmiany kluczy w drugiej wersji protokołu wraz z gotowym obrazem Dockera, który to realizuje, skutecznie zmniejszyło liczbę serwerów z wygasłymi certyfikatami, jednocześnie poprawiając bezpieczeństwo.
Jednak niektórzy dostawcy zdecydowali się z jakichś względów technicznych ustalić termin ważności certyfikatu na dłużej niż 24 godziny. Problem ten w dużej mierze rozwiązano przy pomocy kilku linii kodu w dnscrypt-proxy: użytkownicy otrzymują powiadomienie informacyjne na 30 dni przed wygaśnięciem certyfikatu, inne powiadomienie o wyższym poziomie pilności na 7 dni przed wygaśnięciem oraz krytyczne powiadomienie, jeśli pozostało mniej niż 24 godziny. Dotyczy to tylko certyfikatów, które początkowo miały długi okres ważności.
Takie powiadomienia dają użytkownikom możliwość poinformowania operatorów DNS o zbliżającym się wygaśnięciu certyfikatu, zanim będzie za późno.
Możliwe, że gdyby wszyscy użytkownicy Firefox otrzymali takie powiadomienie, to na pewno ktoś poinformowałby programistów i zapobiegłby wygaśnięciu certyfikatu. "Nie pamiętam żadnego serwera DNSCrypt z listy publicznych serwerów DNS, który miałby wygasły certyfikat w ciągu ostatnich dwóch lub trzech lat" — pisze Frank Denis. W każdym razie, chyba lepiej najpierw ostrzec użytkowników, niż deaktywować rozszerzenia bez uprzedzenia.
Źródło: habr.com
