Szyfrowany DNS: DoH i DoT

Poprzednia lekcja opisała zwykłe zapytanie DNS jako pocztówkę: czytelną dla każdego, kto ją obsługuje po drodze. Istnieją dwa standardy IETF, które wkładają tę pocztówkę do koperty: DNS przez TLS (DoT, RFC 7858) i DNS przez HTTPS (DoH, RFC 8484). Oba szyfrują to samo zapytanie; różnią się głównie sposobem jego przenoszenia.

DNS przez TLS

RFC 7858 wprost stwierdza swój cel: „szyfrowanie zapewniane przez TLS eliminuje możliwości podsłuchu i manipulacji na trasie zapytaniami DNS”, odpowiadając na fakt, że „niemal wszystkie zapytania DNS są wysyłane niezaszyfrowane, co czyni je podatnymi na podsłuch ze strony atakującego”. DoT używa własnego, dedykowanego portu, 853, zamiast zwykłego portu 53. RFC wyjaśnia dlaczego: „to zalecenie przeciwko używaniu portu 53 dla DNS przez TLS ma na celu uniknięcie komplikacji przy wyborze użycia lub nieużycia TLS oraz zmniejszenie ryzyka ataków obniżających wersję zabezpieczeń (downgrade)”.

DNS przez HTTPS

RFC 8484 obiera inną drogę: „każda para zapytanie-odpowiedź DNS jest odwzorowywana na wymianę HTTP”, przenoszoną przez ten sam port 443, którego używa zwykły ruch HTTPS. RFC zaznacza, że ma to dodatkową korzyść: „domyślny port HTTPS 443 oraz możliwość mieszania ruchu DoH z innym ruchem HTTPS na tym samym połączeniu mogą zniechęcić nieuprzywilejowane urządzenia na trasie do ingerowania w operacje DNS”, ponieważ trudniej wyodrębnić i zablokować zapytanie, gdy wygląda ono jak każde inne żądanie sieciowe.

Co ukrywa szyfrowanie, a czego wciąż nie ukrywa

Oba standardy powstrzymują operatora sieci albo podsłuchującego przez Wi-Fi przed odczytaniem twoich zapytań w tranzycie. Żaden z nich nie ukrywa ich przed resolverem, do którego je wysłałeś. RFC 8484 wprost stwierdza, że DoH nie zmienia tego, co może zobaczyć sam serwer: zaznacza, że „różne sposoby przenoszenia zapytań i odpowiedzi DNS faktycznie dostarczają danych, które można wykorzystać do powiązania żądań”, a zwykłe mechanizmy sieciowe, takie jak adresy IP klienta, pliki cookie i informacje o sesji TLS, sprawiają, że „nie wiadomo, by DoH wprowadzał nowe obawy wykraczające poza te związane z HTTPS” po stronie serwera. RFC 7858 podobnie zaznacza, że DoT „nie rozwiązuje innych kwestii bezpieczeństwa w DNS” i że „nawet przy zaszyfrowanych wiadomościach dobrze usytuowana strona może być w stanie wywnioskować pewne szczegóły z analizy czasu i rozmiaru wiadomości”. Krótko mówiąc: szyfrowany DNS przenosi to, kto widzi twoje zapytania, z powrotem na operatora wybranego przez ciebie resolvera, a nie usuwa widoczności całkowicie.

Warto znać jeszcze drugą lukę. Zaszyfrowanie zapytania DNS samo w sobie nie ukrywa, z jaką stroną się potem łączysz: następujące po nim uzgadnianie TLS zwykle zawiera nazwę hosta jawnie widoczną. Jak ujmuje to wyjaśnienie Cloudflare dotyczące Server Name Indication (SNI): „SNI zawiera nazwę hosta w wiadomości Client Hello, czyli pierwszym kroku uzgadniania TLS” — wysyłanej, zanim ustanowione zostanie szyfrowanie. Rozszerzenie o nazwie Encrypted SNI (ESNI), jak wyjaśnia to samo źródło, „rozszerza rozszerzenie SNI, szyfrując część SNI wiadomości Client Hello”, co „uniemożliwia każdemu podsłuchującemu między klientem a serwerem zobaczenie, o jaki certyfikat prosi klient”. Wsparcie dla ukrywania SNI wciąż zależy od zgody zarówno przeglądarki, jak i strony, i nie jest jeszcze sposobem działania każdego połączenia.

Jak wspiera to macOS

Apple dokumentuje konfigurację DNS Settings dla Maca, iPhone’a i iPada, która robi dokładnie to: pozwala urządzeniu „kierować zapytania DNS urządzenia przez zaszyfrowany serwer DNS, używając DNS przez HTTPS albo DNS przez TLS”. Dostarczana jest jako profil konfiguracyjny, który może ograniczyć zaszyfrowany resolver do konkretnych domen za pomocą „uzupełniających domen dopasowania”, albo zastosować go tylko w określonych sieciach za pomocą „reguł na żądanie”, które mogą dopasowywać takie rzeczy jak identyfikator SSID sieci.