Chrome 78 rozpocznie eksperymenty z włączeniem DNS-over-HTTPS

Następny Mozilla Firma Google zgłoszone o zamiarze przeprowadzenia eksperymentu mającego na celu przetestowanie implementacji „DNS over HTTPS” (DoH, DNS over HTTPS) tworzonej dla przeglądarki Chrome. Chrome 78, którego premiera zaplanowana jest na 22 października, będzie domyślnie zawierał pewne kategorie użytkowników przetłumaczony używać DoH. W eksperymencie mającym na celu włączenie DoH wezmą udział tylko użytkownicy, których aktualne ustawienia systemowe określają określonych dostawców DNS uznanych za zgodnych z DoH.

Biała lista dostawców DNS obejmuje usługi Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1), OpenDNS (208.67.222.222, 208.67.220.220), Quad9 (9.9.9.9, 149.112.112.112), Cleanbrowsing (185.228.168.168). 185.228.169.168, 185.222.222.222) i DNS.SB (185.184.222.222, XNUMX). Jeśli w ustawieniach DNS użytkownika zostanie określony jeden z wyżej wymienionych serwerów DNS, DoH w przeglądarce Chrome będzie domyślnie włączony. W przypadku tych, którzy korzystają z serwerów DNS dostarczonych przez lokalnego dostawcę Internetu, wszystko pozostanie niezmienione, a systemowy moduł rozpoznawania nazw będzie nadal używany do zapytań DNS.

Ważna różnica w stosunku do implementacji DoH w Firefoksie, która stopniowo domyślnie włączała DoH zacznie się już pod koniec września jest brak powiązania z jedną usługą DoH. Jeśli domyślnie w przeglądarce Firefox używany CloudFlare DNS, wówczas Chrome zaktualizuje jedynie sposób pracy z DNS do równoważnej usługi, bez zmiany dostawcy DNS. Na przykład, jeśli użytkownik ma ustawiony DNS 8.8.8.8 w ustawieniach systemu, Chrome to zrobi aktywowany Usługa Google DoH („https://dns.google.com/dns-query”), jeśli DNS to 1.1.1.1, to usługa Cloudflare DoH („https://cloudflare-dns.com/dns-query”) oraz itd.

W razie potrzeby użytkownik może włączyć lub wyłączyć DoH za pomocą ustawienia „chrome://flags/#dns-over-https”. Obsługiwane są trzy tryby pracy: bezpieczny, automatyczny i wyłączony. W trybie „bezpiecznym” hosty są określane wyłącznie na podstawie wcześniej buforowanych bezpiecznych wartości (otrzymanych przez bezpieczne połączenie) i żądań za pośrednictwem DoH; powrót do zwykłego DNS nie jest stosowany. W trybie „automatycznym”, jeśli DoH i bezpieczna pamięć podręczna są niedostępne, dane można pobrać z niezabezpieczonej pamięci podręcznej i uzyskać do nich dostęp za pośrednictwem tradycyjnego DNS. W trybie „wyłączonym” najpierw sprawdzana jest współdzielona pamięć podręczna i w przypadku braku danych żądanie jest wysyłane przez systemowy DNS. Tryb ustawia się poprzez dostosowywanie kDnsOverHttpsMode i szablon mapowania serwera za pomocą kDnsOverHttpsTemplates.

Eksperyment mający na celu włączenie DoH zostanie przeprowadzony na wszystkich platformach obsługiwanych w Chrome, z wyjątkiem Linuksa i iOS, ze względu na nietrywialny charakter analizowania ustawień usługi rozpoznawania nazw i ograniczania dostępu do systemowych ustawień DNS. Jeżeli po włączeniu DoH wystąpią problemy z przesyłaniem żądań do serwera DoH (na przykład z powodu jego zablokowania, łączności sieciowej lub awarii), przeglądarka automatycznie zwróci systemowe ustawienia DNS.

Celem eksperymentu jest końcowe przetestowanie implementacji DoH i zbadanie wpływu użycia DoH na wydajność. Należy zauważyć, że w rzeczywistości wsparcie DoH było dodany do bazy kodu Chrome w lutym, ale aby skonfigurować i włączyć DoH wymagany uruchomienie Chrome ze specjalną flagą i nieoczywistym zestawem opcji.

Przypomnijmy, że DoH może być przydatny w zapobieganiu wyciekom informacji o żądanych nazwach hostów przez serwery DNS dostawców, zwalczaniu ataków MITM i fałszowaniu ruchu DNS (na przykład podczas łączenia się z publicznym Wi-Fi), przeciwdziałaniu blokowaniu w DNS poziomie (DoH nie może zastąpić VPN w zakresie obejścia blokad realizowanych na poziomie DPI) lub do organizacji pracy w przypadku braku możliwości bezpośredniego dostępu do serwerów DNS (np. podczas pracy przez proxy). Jeżeli w normalnej sytuacji żądania DNS kierowane są bezpośrednio do serwerów DNS zdefiniowanych w konfiguracji systemu, to w przypadku DoH żądanie ustalenia adresu IP hosta jest hermetyzowane w ruchu HTTPS i wysyłane do serwera HTTP, gdzie resolwer przetwarza żądań za pośrednictwem interfejsu API sieci Web. Istniejący standard DNSSEC wykorzystuje szyfrowanie jedynie do uwierzytelnienia klienta i serwera, ale nie chroni ruchu przed przechwyceniem i nie gwarantuje poufności żądań.

Źródło: opennet.ru