Problem z dystrybucją kluczy w zaszyfrowanym DNS

Wyobraź sobie, że kupiłeś solidny zamek, ale nie możesz dostać do niego klucza. Dokładnie tak wygląda sytuacja milionów użytkowników internetu, którzy próbują korzystać z zabezpieczonego DNS.

Protokoły takie jak DNS-over-HTTPS (DoH) i DNS-over-TLS (DoT) miały chronić przed podsłuchiwaniem zapytań o domeny. W teorii cenzorzy i dostawcy internetu nie powinni widzieć, jakie strony odwiedzamy. W praktyce jednak samo szyfrowanie nie wystarczy, jeśli nie da się go uruchomić.

Nowa strategia cenzury

Zamiast łamać szyfrowanie, coraz częściej po prostu blokuje się możliwość jego uruchomienia. W 2021 roku użytkownicy z Chin zauważyli, że zapytania DoH i DoT działają nieregularnie – raz przechodzą, raz nie. Po analizie okazało się, że tamtejszy firewall nie blokuje wszystkiego na stałe. Zamiast tego stosuje chwilowe blokady adresów IP, które wystarczają, by usługa stała się bezużyteczna.

W praktyce wygląda to tak:

• Zwykły DNS nadal jest fałszowany.
• DNS-over-TLS na porcie 853 jest po prostu odcinany.
• DNS-over-HTTPS na porcie 443 przechodzi przez filtr, ale pojedyncze zapytanie może wywołać tymczasową blokadę.

Efekt jest ten sam – użytkownik rezygnuje.

Problem leży w samym schemacie działania

Szyfrowane protokoły potrzebują kluczy publicznych, żeby nawiązać bezpieczne połączenie. Te klucze trzeba pobrać przez DNS. To oznacza, że zanim cokolwiek zostanie zaszyfrowane, zapytanie musi przejść przez sieć, która może być kontrolowana przez kogoś, kto chce temu zapobiec.

Nowe rozwiązania, takie jak Encrypted Client Hello (ECH), mają ukrywać nazwę odwiedzanej domeny już na etapie handshake’u TLS. Ale żeby ECH zadziałało, przeglądarka musi najpierw pobrać odpowiedni klucz – znowu przez DNS. I koło się zamyka.

Co to oznacza dla twórców stron i usług

Jeśli prowadzisz infrastrukturę, która ma działać globalnie, nie możesz zakładać, że każdy użytkownik na świecie dotrze do Twoich rekordów DNS. Nie możesz też liczyć, że samo włączenie szyfrowania wystarczy. W wielu regionach problemem nie jest złamanie zabezpieczeń, tylko stworzenie takich przeszkód, by korzystanie z nich stało się niepraktyczne.

Trzeba brać pod uwagę, że:

• Rekordy DNS mogą być niedostępne w niektórych krajach.
• Szyfrowanie chroni treść, ale nie chroni przed blokowaniem samego połączenia.
• Cenzura często działa przez spowalnianie i utrudnianie dostępu, a nie przez całkowite odcinanie.

Możliwe kierunki rozwiązań

Obecnie rozważa się kilka podejść jednocześnie:

• Rozproszone systemy dystrybucji kluczy, w tym oparte na DNSSEC lub blockchainie.
• Techniki maskowania ruchu, żeby zapytania DoH wyglądały jak zwykły ruch HTTPS.
• Wykorzystanie sieci Anycast i serwerów w wielu lokalizacjach geograficznych.
• Przeniesienie części mechanizmów dystrybucji kluczy bezpośrednio do aplikacji.

Żadne z tych rozwiązań nie jest idealne. Każde wprowadza kompromisy w szybkości, prostocie lub złożoności.

Najważniejsza lekcja

Ochrona prywatności nie istnieje w oderwaniu od infrastruktury sieciowej. Jeśli projektujesz system, który ma działać niezależnie od lokalnych ograniczeń, musisz zakładać, że ktoś może kontrolować sieć na poziomie dostępowym. Pytanie nie brzmi już tylko „czy dane są szyfrowane”, ale „czy w ogóle da się do tego szyfrowania dotrzeć”.

Problem z dystrybucją kluczy w DNS nie został jeszcze rozwiązany. Najprawdopodobniej rozwiązania będą wymagały większej decentralizacji i większej świadomości po stronie użytkowników.