DNS-over-HTTPS włączone domyślnie w Firefoxie dla użytkowników z USA

Deweloperzy Firefox ogłosili o włączeniu domyślnego trybu DNS przez HTTPS (DoH, DNS over HTTPS) dla użytkowników z USA. Szyfrowanie ruchu DNS uważane jest za kluczowy czynnik ochrony użytkowników. Od dzisiaj we wszystkich nowych instalacjach wykonanych przez użytkowników z USA, DoH jest aktywowany domyślnie. Istniejących użytkowników z USA planuje się przełączyć na DoH w ciągu kilku tygodni. W Unii Europejskiej i innych krajach nie planuje się jeszcze aktywacji DoH domyślnie. nie planują.

Po aktywacji DoH użytkownik otrzymuje ostrzeżenie, które pozwala w razie potrzeby zrezygnować z korzystania z centralizowanych serwerów DNS DoH i wrócić do tradycyjnego schematu wysyłania niezaszyfrowanych zapytań do serwera DNS dostawcy. Zamiast rozproszonej infrastruktury rezolwerów DNS, DoH wykorzystuje powiązanie z określonym serwisem DoH, który można traktować jako pojedynczy punkt awarii. Obecnie oferowana jest współpraca z dwoma dostawcami DNS — CloudFlare (domyślnie) oraz NextDNS.

Zmień dostawcę lub wyłącz DoH można w ustawieniach połączenia sieciowego. Na przykład, można wskazać alternatywny serwer DoH „https://dns.google/dns-query” do łączenia z serwerami Google, „https://dns.quad9.net/dns-query” — Quad9 oraz „https://doh.opendns.com/dns-query” — OpenDNS. W about:config dostępna jest również konfiguracja network.trr.mode, za pomocą której można zmienić tryb pracy DoH: wartość 0 całkowicie wyłącza DoH; 1 — używa DNS lub DoH, w zależności od tego, co jest szybsze; 2 — używa DoH domyślnie, a DNS jako opcję zapasową; 3 — używa tylko DoH; 4 — tryb lustrzany, w którym DoH i DNS są używane równolegle.

Przypomnijmy, że DoH może okazać się przydatny w eliminowaniu wycieków informacji o żądanych nazwach hostów poprzez serwery DNS dostawców, w walce z atakami typu MITM oraz z fałszowaniem ruchu DNS (na przykład przy łączeniu się z publicznymi sieciami Wi-Fi), w przeciwdziałaniu blokadom na poziomie DNS (DoH nie może zastąpić VPN w obszarze omijania blokad realizowanych na poziomie DPI) lub w organizowaniu pracy w przypadku niemożności bezpośredniego dostępu do serwerów DNS (na przykład podczas pracy przez proxy). W standardowej sytuacji zapytania DNS są wysyłane bezpośrednio do określonych w konfiguracji systemu serwerów DNS, podczas gdy w przypadku DoH zapytanie o określenie adresu IP hosta jest enkapsulowane w ruchu HTTPS i wysyłane do serwera HTTP, na którym resolver obsługuje zapytania przez Web API. Istniejący standard DNSSEC stosuje szyfrowanie jedynie w celu uwierzytelnienia klienta i serwera, ale nie chroni ruchu przed przechwyceniem i nie gwarantuje poufności zapytań.

Dla wyboru proponowanych w Firefox dostawców DoH sformułowano wymagania do zaufanych resolverów DNS, zgodnie z którymi operator DNS może używać uzyskiwanych danych do rozwiązywania tylko w celu zapewnienia działania usługi, nie powinien przechowywać logów dłużej niż 24 godziny, nie może przekazywać danych stronom trzecim i ma obowiązek ujawnić informacje o metodach przetwarzania danych. Usługa powinna również zobowiązać się do niecenzurowania, niefiltrowania, nieingerencji oraz nieblokowania ruchu DNS, z wyjątkiem sytuacji przewidzianych w prawie.

Stosowanie DoH należy przeprowadzać ostrożnie. Na przykład w RF adresy IP 104.16.248.249 oraz 104.16.249.249, związane z domyślnym w Firefox serwerem DoH mozilla.cloudflare-dns.com, są zablokowane do lista blokowania Roskomnadzoru na mocy orzeczenia sądu w Stawropolu z dnia 10.06.2013.

Zastosowanie DoH może również prowadzić do problemów w takich obszarach, jak systemy kontroli rodzicielskiej, dostęp do wewnętrznych przestrzeni nazw w systemach korporacyjnych, wybór tras w systemach optymalizacji dostarczania treści oraz wykonywanie nakazów sądowych w zakresie przeciwdziałania rozpowszechnianiu nielegalnych treści i wykorzystywaniu nieletnich. Aby obejść te problemy, wdrożono i przetestowano system kontroli, który automatycznie wyłącza DoH w określonych warunkach.

W celu wykrycia korporacyjnych resolverów przeprowadza się kontrole nietypowych domen najwyższego poziomu (TLD) oraz zwraca się adresy intranetowe przez systemowy resolver. Aby ustalić, czy kontrola rodzicielska jest aktywna, podejmuje się próbę rozwiązania nazwy exampleadultsite.com; jeśli wynik nie zgadza się z rzeczywistym adresem IP, uznaje się, że blokada treści dla dorosłych jest aktywna na poziomie DNS. Jako oznaki sprawdzane są również adresy IP Google i YouTube pod kątem ich zamiany na restrict.youtube.com, forcesafesearch.google.com oraz restrictmoderate.youtube.com. Te kontrole umożliwiają atakującym, którzy kontrolują pracę resolvera lub mogą ingerować w ruch, symulowanie takiego zachowania w celu wyłączenia szyfrowania ruchu DNS.

Praca przez wspólny serwis DoH może również potencjalnie prowadzić do problemów z optymalizacją ruchu w sieciach dostarczania treści, które wykonują równoważenie ruchu z wykorzystaniem DNS (serwer DNS sieci CDN tworzy odpowiedź, biorąc pod uwagę adres resolvera i wydaje najbliższy host w celu uzyskania treści). Wysyłanie zapytania DNS z najbliższego do użytkownika resolvera w takich CDN kończy się zwróceniem adresu najbliższego do użytkownika hosta, ale przy wysyłaniu zapytania DNS z zcentralizowanego resolvera zostanie wydany adres hosta najbliższego do serwera DNS-over-HTTPS. Testy w praktyce wykazały, że korzystanie z DNS-over-HTTP przy użyciu CDN niemal nie wprowadzało opóźnień przed rozpoczęciem przesyłania treści (dla szybkich połączeń opóźnienia nie przekraczały 10 milisekund, a na wolniejszych kanałach komunikacyjnych odnotowano nawet przyspieszenie działania). Aby przesłać do resolvera CDN informacje o lokalizacji klienta, rozważano również zastosowanie rozszerzenia EDNS Client Subnet.

Źródło: opennet.ru