Co to jest DNS‑over-HTTPS i dlaczego nie wiadomo, co o nim myśleć?

Prototypowy protokół IETF nazwano, mało odkrywczo acz trafnie, DNS-over-HTTPS i obecnie działa on eksperymentalnie w ramach przeglądarki Mozilla Firefox i kilku wariantach Chromium. Z jednej strony brzmi on jak naturalne następstwo przejścia całego internetu na ruch szyfrowany, z drugiej jednak jest to kompletne pomieszanie warstw i rozwiązań. Powinno to być szczególnie widoczne dla nieco bardziej wprawnego oka sieciowca. Na czym polega więc nowy wynalazek od Mozilli (nie do końca od Mozilli, ale o tym później)? I czy powinniśmy mu w ogóle poświęcać czas?

Krótka powtórka – co to jest DNS? Krótko mówiąc, jest to usługa rozwiązywania nazw domenowych na numeryczne adresy sieciowe. DNS to oczywiście o wiele więcej (podobnie jak DHCP to nie tylko adresy IP!), ale na potrzeby niniejszego tematu owa definicja jest wystarczająca. Mimo swojego rozbudowania, DNS jest w swojej naturze Dość Prosty™. Podobnie, jak pozostałe rdzenne usługi sieci internetowej, działa na dedykowanym porcie: stosuje datagramy UDP przesyłane przez port 53.

Każdą opowieść o DNS należy zacząć od stwierdzenia, z którym niejeden administrator się zgodzi: serwer DNS w opinii wielu jest przestarzałym kłębkiem kłopotów. I choć nie jestem zwolennikiem „postępu za wszelką cenę” i niekontrolowanego wzrostu złożoności, niektórych wad systemu DNS nie sposób dziś obronić. Zapewne stwierdzenie to oburzy pewnych brodatych (również mentalnie) mistrzów, wciąż słabo znoszących, że świat nie podaje już ilości RAMu w kilobajtach. DNS jest wedle ich wykładni kanonicznej klasyczną usługą sieciową i software’ową oczywistością. A jak ktoś ma z nim problemy, to po prostu się nie zna.

Żadna doza tajemnej wiedzy nie przykryje jednak faktu, że DNS-owi nie można ufać. Nie można tego zrobić z powodów formalnych, a więc niemal z definicji. Nie istnieje metoda zapewnienia, że dane oferowane przez DNS są najnowsze i aktualne. Nie ma żadnego sposobu upewnienia się, że dane DNS nie są sfałszowane (dlatego pamięci podręczne DNS tak łatwo zatruć, a następnie dokonać propagacji owego zatrucia). System nazw domenowych jest więc mocno odporny na awarie, ale kompletnie bezbronny w przypadku złośliwości.

To paradoks systemów wojskowych: intuicja podpowiada, że powinny być superbezpieczne, podczas gdy zakres ich wykorzystania ze swej natury przyjmował wysoki clearance użytkownika. W efekcie prawdopodobnie nakładał na każdą ze stron groźbę surowej odpowiedzialności karnej za wszelkie działania na szkodę Departamentu Obrony USA. Zapewne to właśnie dlatego protokoły internetowe powstały bez wbudowanych zabezpieczeń. Cenę za to płacimy do tej pory.

Naturalnie, miały miejsce próby napraw i ulepszeń protokołu DNS. Najważniejszą z nich jest DNSSec, czyli zbiór rozszerzeń zwiększających bezpieczeństwo. Rozszerzeń. Bo protokołów fundamentalnych nie da się zmienić ani poprawić. Można je jedynie rozszerzać, bo inaczej przestanie działać jakiś niewyobrażalnie drogi sprzęt na customowym systemie operacyjnym, niezaopatrzony w dokumentację i stworzony przez ludzi, którzy dawno nie żyją. Toteż DNSSec uprzejmie dodaje opcjonalne pola odpowiedzi do ruchu DNS, a klient łaskawie może z nich skorzystać albo wcale nie.

DNSSec, poza potężnym bólem podczas wdrażania, zapewnia bardzo niewiele rzeczy, są to niemniej rzeczy wysoce istotne. Przede wszystkim, DNSSec wprowadza do hierarchii DNS coś na kształt infrastruktury klucza publicznego (PKI). Należy mocno podkreślić tu słowa „coś na kształt”, celem (nieskutecznego zapewne) uniknięcia żywiołowych głosów sprzeciwu. Każdy rekord nazw w ramach DNSSec jest podpisany. Dzięki temu klient może – ale nie musi, jeżeli go to nie obchodzi – upewnić się, że odpowiedź na pewno pochodzi od odpytywanego serwera nazw i po drodze nikt nie dopisał nic do niej na kolanie. Pośrednio, można dzięki temu dowiedzieć się, czy ktoś próbował modyfikować taką odpowiedź. W pewnych okolicznościach to cenna informacja.

Zależności czasowe sprawiają też, że DNSSec pozwala zagwarantować aktualność wpisów. Powyższe zalety są niezaprzeczalne, ale na nich lista w zasadzie się kończy. DNS, nawet z wdrożonymi podpisami kryptograficznymi dalej pozostaje datagramową usługą operującą na porcie 53. Usługą, której ruch jest niezaszyfrowany.

No właśnie. Ruch HTTP otrzymał ostatnimi laty dużo miłości i obecnie jest powszechnie zaszyfrowany i „bezpieczny” (chyba, że jesteśmy w Kazachstanie). Efekt ten osiągnięto nadbudowując nad transfer hipertekstów tak wiele dodatków, że nowy, szyfrowany ruch jest w praktyce innym, niekompatybilnym protokołem – HTTPS. Mocno zadbaliśmy o to, by nikt nie widział co takiego przesyłamy w chronionym kanale TLS: nie da się podejrzeć zarówno wyników, jak i samych kwerend URL. Jednocześnie jednak, celem wygenerowania ruchu TLS „we właściwym kierunku”, muszą zostać wykonane zapytania DNS. A ten protokół, będący de facto drugą, równolegle wykorzystywaną usługą, został nieco zapomniany.

Podobnie, jak w przypadku HTTP i jego młodszego wariantu HTTPS, zastosowanie szyfrowania i nowocześniejszych metod zabezpieczeń wymusza w praktyce rozbudowanie protokołu do poziomu, na którym nie ma on szans na zgodność z poprzednikiem. Świadomość tego faktu była wyzwalającą motywacją dla inżynierów Mozilli, a jej efektem jest właśnie DNS-over-HTTPS. Jak więc działa to z kolei cudo?

Najpierw uwaga na marginesie: zapytanie DNS nie jest podzbiorem zapytania HTTP. Innymi słowy, przeglądarka internetowa nie pyta, w ramach pobierania strony WWW, serwera DNS o „namiary” na oczekiwany serwer. Rolę klienta DNS spełnia stos sieciowy systemu operacyjnego. To dla niektórych oczywiste, ale nie dla każdego, głównie ze względu na znacznie mniej wyodrębnioną „aplikację” do DNS w porównaniu z aplikacją do WWW, jaką jest przeglądarka.

Metoda DNS-over-HTTPS, podobnie jak DoT (DNS over TLS/SSL) umieszcza komunikację DNS w zaszyfrowanym kanale komunikacji strzeżonym certyfikatem. Upodobnienie komunikacji tego typu do ruchu HTTPS niesie za sobą zbiór konsekwencji. Przede wszystkim, przesuwa punkt zaufania z adresu IP (systemowego adresu serwera nazw, zaoferowanego np. przez DHCP) na klucz prywatny, co czyni konfigurację niepodatną na akt podmiany serwera pod danym adresem liczbowym. Zmiany są jednak głębsze: zastosowanie TLS usuwa ważną cechę DNS, czyli operowanie na datagramach. Oznacza to, że ruch DoT z definicji musi mieć zagwarantowaną ciągłość. Jest to wbrew specyfikacji DNS, ma jednak swoje zalety.

System DNS ma architekturę hierarchiczną (dlatego jest odporny na częściowe awarie sieci). Żądania rozwiązania nazw często podróżują po wielu serwerach NS zanim zakończą się zwycięską odpowiedzią. Nie są więc, w przeciwieństwie do HTTPS, „ciągłą sesją”. Podróż żądania w dalszym ciągu może być zawiła – tu specyfika DNS się nie zmienia – ale każda sesja, która się na nią składa, jest chroniona przez TLS. Wyklucza to możliwość ścisłej kontroli ruchu, jednocześnie wciąż zapewniając ochronę przed manipulowaniem odpowiedzią.

Jak świetnie stwierdził Geoff Huston: *”Certyfikaty nie mogą zaświadczyć, co jest prawdą, a co fałszem. Mogą jedynie potwierdzić zgodność z oryginałem”. *Doskonale naświetla to różnicę między klasycznym, standardowym DNSSec, a DoT. To pierwsze jest sędzią, drugie – bardziej notariuszem. Różnice między nimi odzwierciedlają naturę zagrożeń właściwych dla czasów ich powstania. Niegdyś problemem było poświadczenie tożsamości, dziś walczymy o swoją prywatność.

Wypada też powiedzieć jasno, że DoT i DoH to nie to samo. Obie metody efektywnie wrzucają komunikację DNS w szyfrowany kanał TLS, istotnie, ale różnica polega na tym, jak to robią. Zarówno DoT jak i DoH są aspirującymi standardami RFC (odpowiednio 7858 i 8484), różni je jednak pewna fundamentalna kwestia. Port. DoT posiada swój dedykowany port, na tej samej zasadzie, jak HTTPS ma port 443 w przeciwieństwie do http z portem 80. DoH stosuje po prostu ruch HTTPS, którego treść ma być wykorzystywana jako informacje DNS. Wracamy w ten sposób do naszej obserwacji sprzed paru chwil: zapytanie DNS nie jest częścią połączenia w ruchu IP.

Pozdrówmy ponownie naszych brodatych administratorów UNIX, niechętnych wobec rozszerzania DNS. Zgodzą się oni zapewne, że ruch DNS przez HTTPS to nieco absurdalna matrioszka: są to przecież dwie oddzielne usługi. Jeżeli chce się szyfrowania, należy stworzyć szyfrowany wariant usługi, a więc DNS-over-TLS. Pomysł z DoH wygląda w porównaniu z nim na kwintesencję wszystkiego, co najgorsze w dzisiejszym internecie. Sklecone na szybko dzieło patałachów, którzy nie potrafią skonfigurować firewalla. Dlaczego? Otóż:

• nie tworzy nowego wariantu usługi, a jedynie przepuszcza „trudny” ruch przez „łatwy” protokół. HTTPS zna każdy, DNS-a wszyscy albo się boją, albo rozliczają w zbyt wysokich stawkach za godzinę
• przekierowuje cały już de facto ruch sieciowy na jeden port, znosząc całkowicie koncepcję portu, bo łatwiej filtrować wszystko na wyższych warstwach, zamiast zrozumieć i poprawnie zabezpieczyć niższe
• pod pozorem wyższej kontroli (łatwiejszy protokół), w praktyce tę kontrolę zmniejsza, mieszając oba rodzaje żądań w jednym tyglu
• przerzuca zarządzanie rozwiązywaniem nazw z systemu na aplikację (przeglądarkę), pogłębiając stan, w którym Google Chrome jest drugim, równorzędnym systemem względem Windows i niejako alternatywnym ośrodkiem władzy
• jest po prostu brzydkie

Powyższe argumenty przytoczył nie kto inny, a Paul Vixie, jeden z architektów standardu RFC DNS. Trudno odmówić mu racji, ale głównie dlatego, że trudno się kłócić z mądrzejszymi od siebie, nawet gdy się mylą. Tymczasem DoH ma jednak trochę sensu.

Oczywiście, Vixie patrzy na sprawę z perspektywy elegancji technicznej. Ale dzisiejsza rzeczywistość „nie pozwala nam mieć ładnych rzeczy”. Manipulacja serwerami DNS jest jedną z najprostszych metod odcięcia całego kraju od internetu. Iran i Etiopia eksperymentują rzekomo z takimi pomysłami, Chiny egzystują tak od lat i śledzą tych, którzy usiłują się wydostać, a Rosja testuje swoje pomysły. DNS stał się, jak wszystko ostatnio, kwestią polityczną i łatwo być dziś zdania, że prawa człowieka mają większą wagę, niż inżynieryjna estetyka.

Zresztą, z lekką dozą przesady możemy stwierdzić, że DoT „przegrywa”: będąc alternatywną usługą, wymaga obsługi ze strony systemów operacyjnych, a stabilne wersje klienckich Windowsów i macOS obecnie jej nie oferują. Inaczej sprawa ma się z DoH, gdzie królują przeglądarki internetowe, ponownie rozszerzając swoją władzę nad systemami. Obsługę DNS-over-HTTPS da się włączyć w przeglądarce Mozilla Firefox oraz Google Chrome Canary.

W obu przypadkach są to funkcje dość mocno związane z dostawcą usługi, czyli firmą CloudFlare, co nie każdemu może odpowiadać. To również znak czasu: niegdyś ustawialiśmy ręcznie adresy OpenDNS, dziś – serwer nazw komercyjnego dostawcy infrastruktury chmurowej, dostępny po HTTPS.

Z Mozillą będzie łatwo: w głównym panelu ustawień, na samym dole sekcji Ogólne, znajduje się dział Sieć. W nim, jako ostatnia opcja, figuruje możliwość włączenia DNS-over-HTTPS, z użyciem serwera od CloudFlare.

W przypadku Google Chrome jest znacznie trudniej. Jak możemy przeczytać na systemie śledzenia błędów projektu Chromium, konieczne jest dodanie parametru wiersza polecenia do uruchomianej instancji Chrome. A więc dla nowej funkcji nie zaimplementowano jeszcze przełącznika w postaci flagi w ustawieniach zaawansowanych.

Warto dodać, że aby parametr zadziałał, konieczny jest Chrome z linii Canary, a autorem wskazówki, jak włączyć DoH w Chrome jest członek projektu Blink, legitymujący się mailem w domenie „@microsoft.com”…

Czas pokaże, jaka jest przyszłość DNS i czy najbliższe lata, w ramach „ochrony przed cenzurą” nie wyrwą go z jego zdecentralizowanych ram, wtłaczając pod opiekę wielkich internetowych korporacji.