Zaszyfruj, zachowaj bezpieczeństwo: praca z ESNI, DoH i DoT

Najnowsze osiągnięcia w zakresie ochrony prywatności w Internecie obejmują szyfrowane wskazanie nazwy serwera TLS (ESNI) i szyfrowany DNS w postaci DNS przez HTTPS (DoH), które są uważane za wysoce kontrowersyjne przez podmioty zbierające dane.

Oto krótkie spojrzenie na powody, dla których istnieją, szczegóły na temat tego, czym są, oraz technologię stojącą za tym, jak działają.

DNS musi działać poprawnie

Połączenia wirtualnej sieci prywatnej (VPN) podzielonego tunelu, protokół automatycznego wykrywania proxy sieci (WPAD), DNS multiemisji z zerową konfiguracją (mDNS), czarne listy czasu rzeczywistego (RBL) i wiele innych szeroko stosowanych technologii ulega awarii, gdy DNS działa poprawnie.

Przełamywanie Internetu dla zysku i sławy

Już w 2003 r. internauci dowiedzieli się o znaczeniu DNS w skali globalnej, gdy firma, która prowadziła wówczas domenę najwyższego poziomu (TLD) .com , zdecydowała się zaprzestać wysyłania odpowiedzi NXDOMAIN . Zamiast tego podszywali się pod nieistniejącą domenę, próbując wyświetlać więcej reklam, sprzedawać więcej domen i ostatecznie generować większe przychody. Nieoczekiwany efekt domina wywołał publiczną debatę i potępiający raport Komitetu Doradczego ds. Bezpieczeństwa i Stabilności (SSAC) ICANN. Ten projekt został rzeczywiście zamknięty, ale z technicznego punktu widzenia luka się utrzymała.

Później, w 2008 roku, kolejna próba manipulacji DNS dla zysku została publicznie wywołana, gdy niektórzy z największych dostawców usług internetowych wprowadzili różne sposoby ataków cross-site scripting na dosłownie każdą stronę internetową. Ze względu na charakter luk mogą zostać wykorzystane nawet witryny hostowane w sieci prywatnej i niedostępne z Internetu.

Znaleziony problem nie dotyczy podstawowych protokołów internetowych, ale jest to problem pogarszany przez niewłaściwą monetyzację niektórych funkcji DNS.

Paul Vixie, Konsorcjum systemów internetowych (ISC)

Chociaż prawdą jest, że same protokoły nie są tak naprawdę przyczyną problemu, prawdą jest również, że protokoły te nie zapobiegają nadużywaniu systemu przez złych aktorów. Tak więc z technicznego punktu widzenia luka utrzymywała się.

Przełamywanie Internetu w celu nadzoru i cenzury

W 2016 roku zaobserwowano, że dostawcy usług internetowych w Iranie manipulowali DNS. Tym razem, zamiast wstrzykiwać reklamy, zablokowali dostęp do serwerów pocztowych 139 z 10 000 najlepszych domen w Internecie. Nie jest jasne, czy jest to celowa polityka odmowy usługi przeciwko tym konkretnym domenom – podobnie jak cenzura światowej sławy w Chinach – czy może tylko przykład złej implementacji technicznej dowolnego systemu przechwytującego zapytania DNS.

Niewiedza o tym, dlaczego DNS jest przechwytywany, jest ważna: nawet jeśli odłożymy na bok kwestie moralne i prawne dotyczące powszechnego nadzoru i cenzury, technologia wykorzystywana do tego celu jest – z natury rzeczy – niezgodna ze standardami i może bardzo dobrze ingerować w Twoje normalne, codzienne, rozsądne i zgodne z prawem korzystanie z Internetu.

Jednak z technicznego punktu widzenia usterka się utrzymywała.

Łamanie Internetu w nikczemnych celach

Oczywiście nie tylko podmioty komercyjne i rządy próbują przechwytywać ruch internetowy na własne potrzeby. Istnieje wiele przykładów przestępców próbujących przejąć połączenia, zwykle w celu kradzieży danych użytkownika lub nakłonienia użytkowników do ujawnienia ważnych danych uwierzytelniających. Co najważniejsze, zatruwanie pamięci podręcznej DNS było wykorzystywane do kierowania użytkowników do witryn phishingowych, wdrażania oprogramowania ransomware, wdrażania botnetów, odmowy świadczenia usług określonym witrynom i wielu innych.

Wycieki TLS Kto łączy się z kim

Transport Layer Security (TLS) to technologia stojąca za HTTPS, bezpieczną wersją HTTP, na której wszyscy polegamy na co dzień. Nawiązanie połączenia TLS wymaga kilku kroków, w czasie których serwer potwierdza swoją tożsamość poprzez przedstawienie certyfikatu i wymieniane są nowe klucze szyfrujące.

Bardzo ważnym krokiem jest użycie przez serwer certyfikatu do potwierdzenia swojej tożsamości, ponieważ częścią certyfikatu jest asymetryczny publiczny klucz szyfrujący.

Gdy klient wysyła wiadomość przy użyciu tego klucza, tylko serwer, który jest w posiadaniu skojarzonego klucza prywatnego, może odczytać wiadomość. W rezultacie każda osoba przechwytująca lub podsłuchująca połączenie jest zablokowana i nie może odczytać zawartości.

Jednak ta początkowa wymiana nadal odbywa się w trybie jawnym, bez szyfrowania, co oznacza, że ​​obserwator zawsze będzie znał tożsamość serwera.

Ochrona domeny

Kilka narzędzi typu anty-cenzura pracowało nad tym wyciekiem w TLS przez pewien czas, używając techniki znanej jako domena frontingu. Wykorzystuje to fakt, że po ustanowieniu połączenia HTTPS większość dużych dostawców usług hostingowych nie sprawdza, czy nazwa hosta prezentowana w każdym żądaniu HTTP jest zgodna z nazwą użytą w uzgadnianiu TLS. Jeśli chodzi o narzędzia do ochrony prywatności, uznano to za użyteczną funkcję umożliwiającą tajną komunikację z ukrytą witryną. Dla dostawców hostingu i zbieraczy danych było to postrzegane jako nadużycie sposobu implementacji specyfikacji.

Jest to samo w sobie luka w zabezpieczeniach i jako taka została naprawiona przez kilku głównych dostawców hostingu, w tym AWS.

Rozwiązanie problemu poprzez zmianę standardu: szyfrowany SNI (ESNI)

Ideą ESNI jest zapobieganie wyciekowi jakichkolwiek danych przez TLS poprzez szyfrowanie wszystkich wiadomości, w tym początkowej wiadomości Client Hello . To pozostawia każdego obserwatora w całkowitej nieświadomości tego, jaki certyfikat serwera przedstawia serwer.

W tym celu klient potrzebuje klucza szyfrowania przed nawiązaniem połączenia. Dlatego ESNI wymaga umieszczenia określonego zestawu kluczy szyfrowania ESNI w rekordzie SRV w systemie DNS.

Dokładne szczegóły wciąż się jednak zmieniają, ponieważ specyfikacja nie została jeszcze sfinalizowana. Mimo to implementacja ESNI została już wprowadzona do produkcji przez Mozilla Firefox i Cloudflare.

Zabezpieczanie i szyfrowanie DNS

Aby klucze ESNI były dostarczane bez przechwycenia, ważne jest, aby zabezpieczyć się przed manipulacją DNS.

Już od 1993 roku społeczność internetowa próbowała zabezpieczyć DNS. IETF zauważa, że ​​na wczesnych spotkaniach poświęconych rozwiązywaniu problemów omówiono:

1. Ochrona przed ujawnieniem danych DNS osobom nieupoważnionym
2. Zapewnienie integralności danych
3. Uwierzytelnianie pochodzenia danych

Spotkania te zaowocowały w 1997 roku standardem Domain Name System Security Extensions (DNSSEC). Standard zdecydował się rozwiązać dwa z trzech z tych problemów, ponieważ zespół projektowy podjął wyraźną decyzję o wykluczeniu wszystkich zagrożeń ujawnienia danych, które są poza zakresem.

W związku z tym DNSSEC oznacza, że ​​użytkownicy mogą ufać, że odpowiedzi na ich zapytania DNS są zgodne z intencjami właścicieli domen. W kontekście ESNI oznacza to, że wiemy, że klucz, który otrzymujemy, nie został naruszony i na szczęście wiele wspomnianych wyżej luk znika, gdy używany jest DNSSEC. Nie zapewnia jednak prywatności i dlatego nadal jest podatny na problemy związane z systemami nadzoru i cenzury.

Niestety, ponieważ jest on w pełni kompatybilny wstecz z „niebezpiecznym DNS” i dość trudny do poprawnego wdrożenia, zastosowanie DNSSEC jest bardzo niskie. Wielu właścicieli domen poddaje się częściowo próbując ją skonfigurować, o czym świadczą liczne nieprawidłowe i częściowo skonfigurowane konfiguracje obserwowane na wolności.

DNS przez HTTPS (DoH)

Aby klucze ESNI były dostarczane bez wiedzy obserwatorów, którą witrynę próbują odwiedzić użytkownicy, ważne jest, aby zabezpieczyć się przed podsłuchiwaniem DNS. W związku z tym całkiem logiczne i zrozumiałe jest stwierdzenie, że zaszyfrowany DNS (tak jak w przypadku DoH) jest dobrą rzeczą. Jednak w obecnej formie DNS nie jest szyfrowany.

Istnieją działania Mozilli, Google, APNIC, Cloudflare, Microsoft i innych, aby to zmienić.

Idealne szyfrowane wrażenia użytkownika

Użytkownik, który chce wykorzystać powyższe technologie, może mieć dość długą listę wymagań, jeśli chodzi o praktyczne szczegóły UX pracy z szyfrowaniem. Prawdopodobnie chcieliby uniknąć takich rzeczy jak:

• Zmuszanie do korzystania z konkretnego dostawcy usług DNS (bez względu na to, jak dobry jest) lub wybór, aby był niewidoczny lub trudny do znalezienia
• Każda aplikacja na urządzeniu inaczej obsługuje DNS (np. Firefox może znaleźć rzeczy, których Safari nie może)
• Wszystkie aplikacje na urządzeniu muszą tworzyć w sobie własną bezpieczną implementację DNS
• Konieczność wielokrotnego ręcznego konfigurowania DNS
• Konieczność włączenia prywatności i bezpieczeństwa
• Aplikacje powracają do niezabezpieczonego działania bez zgody użytkownika

Użytkownicy dbający o prywatność chcieliby zamiast tego:

• Prywatność przed nieuzasadnionym nadzorem przez kogokolwiek
• Ochrona przed ukierunkowanymi reklamami, na które nie wyrazili zgody
• Ochrona własnych opublikowanych treści (np. na osobistej stronie internetowej) przed zmianą lub manipulacją w drodze do innych widzów
• Zapewnienie, że widzowie ich własnych opublikowanych treści nie będą mieli kłopotów tylko dlatego, że mają do nich dostęp
• Aby nadal mieć możliwość kontrolowania DNS we własnych sieciach (ponieważ czasami DNS o podziale horyzontu jest dobry do utrzymywania zasobów wewnętrznych w zakresie do użytkowników wewnętrznych)
• Możliwość włączenia lub przynajmniej rezygnacji z filtrowania na poziomie DNS (np. Quad9, CleanBrowsing i OpenDNS Family Shield)
• Łatwa, bezproblemowa konfiguracja (np. DHCP)
• Aby zostać poproszony o zgodę na korzystanie z DNS bez szyfrowania
• Ochrona nie tylko dla ruchu przeglądarki, ale dla wszystkich rodzajów ruchu, np. poczty e-mail, Slack, VoIP, SSH, VPN itp.

Bieżące wysiłki w zakresie szyfrowania

Jakie opcje są dostępne dla użytkowników z powyższymi celami?

Rozwiązanie Mozilli to początek, ale daleki od ideału. Zabezpieczają tylko Firefoksa; domyślnym ustawieniem jest zastąpienie ustawień systemu operacyjnego na rzecz wyboru dostawcy (Cloudflare) bez mówienia tego, i po cichu powraca do braku bezpieczeństwa (w przypadku zablokowania zaszyfrowanego DNS itp.)

Rozwiązanie Google to lepsze podejście. Zabezpieczają Androida 9+ — co dotyczy wszystkich aplikacji. (Nie jestem pewien co do ich planów dotyczących systemu operacyjnego Chrome, ale podejrzewam, że jest w toku). Zabezpieczają również Chrome na wszystkich platformach, ale uruchamiają zabezpieczenia tylko wtedy, gdy platforma hosta jest skonfigurowana do korzystania z dostawcy, który obsługuje zabezpieczenia. Jest to dobre pod względem wyboru użytkownika, ale nie idealne, ponieważ po cichu wraca do niepewności.

Wszystkie inne główne przeglądarki również wdrażają wsparcie.

W idealnej sytuacji dla użytkowników szersza społeczność twórców oprogramowania i systemów operacyjnych:

1. Przestań wdrażać nowe funkcje bezpieczeństwa DNS na poziomie aplikacji
2. Zacznij je wdrażać na poziomie systemu operacyjnego
3. Przestrzegaj konfiguracji na poziomie systemu operacyjnego lub uzyskaj zgodę użytkownika

Implementując zaszyfrowany DNS na poziomie systemu operacyjnego, moglibyśmy nadal stosować ten sam rozproszony model, który mamy obecnie w przypadku przeliczników DNS. Uruchamianie własnego serwera DNS we własnej sieci i możliwość zabezpieczenia tego przelicznika, ma sens, aby nadal być opcją, podobnie jak korzystanie z scentralizowanego dostawcy.

Linux i BSD mają już tę funkcjonalność z różnymi dostępnymi opcjami. Niestety, o ile mi wiadomo, żadna dystrybucja nie włącza domyślnie żadnego z nich. Sprawdź nss-tls, jeśli chcesz coś, co po prostu podłączy się do glibc.

Implementacja Google DNS-over-TLS w Androidzie 9+ również to już robi. Działa poprzez testowanie serwera DNS pod kątem obsługi szyfrowania. Jeśli to ma, to go użyje. Jeśli tak się nie stanie, to – podobnie jak w Chrome – kontynuuje działanie w niezabezpieczony sposób, bez pytania o zgodę.

Warto zauważyć, że większość sieci jest skonfigurowana do korzystania z serwerów DNS, które nie obsługują szyfrowania, więc rozwiązanie wbudowane w Androida nie zmienia jeszcze niczego dla większości użytkowników. Może lepiej byłoby zaproponować powrót do scentralizowanego zaszyfrowanego DNS w przypadkach, gdy zdecentralizowany nie obsługuje szyfrowania.

W przypadku urządzeń typu Apple i Microsoft obsługa zaszyfrowanego systemu DNS jeszcze oficjalnie nie pojawiła się w momencie pisania tego tekstu. Ponieważ Microsoft ogłosił w listopadzie 2019 r. swoje zamiary obsługi zaszyfrowanego DNS, mam nadzieję, że Apple wkrótce to zrobi.

Zaszyfrowane rozwiązania DNS

Istnieje kilka obejść w postaci serwerów proxy, które można uruchomić lokalnie. Dzięki temu komputer użytkownika przesyła do siebie niezaszyfrowany DNS, który następnie przesyła zaszyfrowany DNS do dowolnego dostawcy, którego ma używać. Nie jest to idealne rozwiązanie, ale jeśli chodzi o obejście, jest przyzwoite.

Inspiracją do napisania tego artykułu jest serwer proxy DNSCrypt, który jest bardzo stabilny, ma wiele dzwonków i gwizdków i jest wieloplatformowy. Obsługuje starszy protokół DNSCrypt, a także nowszy protokół DNS over TLS (DoT) i DNS over HTTPS (DoH).

Dla użytkowników systemu Windows dostępny jest instalator i graficzny interfejs użytkownika o nazwie Simple DNSCrypt, który jest kompletny i bardzo łatwy w użyciu.

Polecam, ale pamiętaj, że świat prawdopodobnie nie jest jeszcze na ciebie gotowy i może być konieczne wyłączenie go od czasu do czasu (np. gdy musisz skorzystać z portalu przechwytującego w ulubionej kawiarni lub w sieci LAN impreza).

Inne opcje

Dodatkowo istnieje serwer DNS Technitium, który obsługuje szyfrowany DNS, jest wieloplatformowy (Windows, MacOS, Linux na ARM/Raspberry Pi) i oferuje zgrabny interfejs sieciowy. Jest pod „inne”, ponieważ jest to bardziej wszechstronne narzędzie niż rozwiązanie specyficzne dla tego problemu. (Prawdopodobnie byłby to dobry wybór, jeśli chcesz uruchomić swój serwer DNS Raspberry Pi w domu. Chciałbym usłyszeć opinie od osób, które go wypróbowują w komentarzach poniżej.)

W przypadku urządzeń z systemem Android lub iOS (iPhone, iPad itp.) istnieje również aplikacja 1.1.1.1, która wymusza wszystkie zapytania DNS za pośrednictwem usługi Cloudflare Encrypted DNS. Słyszałem, że są też bardziej elastyczne aplikacje, takie jak Intra, ale nie poświęciłem jeszcze czasu na ich testowanie.

Oczywiście możesz także włączyć szyfrowany DNS zarówno w Firefoksie, jak i Chrome – pamiętaj tylko o wszystkich zastrzeżeniach omówionych powyżej.

Niezawodność DNS: zadanie numer jeden

Istnieje wiele kontrowersji związanych z technologią prywatności w Internecie. Jednak jeśli chodzi o wdrażanie środków bezpieczeństwa i prywatności, technologia, o której mowa, nie polega przede wszystkim na utrzymywaniu tajemnic. Chodzi o zapewnienie niezawodności i zagwarantowanie, że technologia będzie nadal działać poprawnie pomimo zachowania innych. Musimy jednak pamiętać, że tak jak technologia bez zabezpieczeń prywatności jest zła, tak źle wdrożone zabezpieczenia mogą tylko pogorszyć sytuację.