Top-office11.ru

IT и мир ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Защита dns запросов

О последствиях криптозащиты DNS-запросов

На этой неделе Microsoft объявила о поддержке в будущих обновлениях своей операционной системы Windows 10 протокола DNS over HTTPS (DoH), позволяющего шифровать запросы к DNS-серверам, подробности см., например, здесь. Microsoft объясняет инновацию тем, что сохранить децентрализацию DNS можно только в случае всеобщего принятия и использования протокола DoH, что и может быть обеспечено его поддержкой в Windows. Заявление Microsoft активно обсуждается в России: и специалистов, и обывателей прежде всего интересует, как поддержка DoH повлияет на исполнение закона об устойчивом Рунете. D-Russia.ru предлагает вашему вниманию текст нашего эксперта Александра Венедюхина.

Обычные клиентские компьютеры, а точнее — их операционные системы, используют для поиcка информации в DNS внешние серверы, называемые резолверами. Обычно это сервер, предоставленный в автоматическом режиме ближайшим провайдером доступа (интернет-провайдером). Иногда — общедоступный сервер, вроде хорошо известных 8.8.8.8 (Google) и 1.1.1.1 (Cloudflare), работу с которым пользователь должен настроить вручную. DNS-over-HTTPS — технология, защищающая пользовательский DNS-трафик на «последней миле», то есть на участке между компьютером пользователя и только что упомянутым резолвером (сервер, осуществляющий поиск в DNS).

Технология скрывает от третьей стороны, прослушивающей канал, содержание DNS-запросов и DNS-ответов. В самом простом случае таковыми будут доменное имя (запрос) и IP-адрес (ответ). Традиционно, в классической DNS, соответствующая информация передаётся в открытом виде. DNS-over-TLS (transport layer security, протокол криптозащищённой передачи данных – ред.) – это гораздо более технологичный вариант решения той же задачи, который, тем не менее, в контексте обычного пользователя Интернета можно считать аналогичным DNS-over-HTTPS (собственно, в этом последнем словосочетании, HTTPS – тоже работает через TLS).

Как технология «последней мили» DNS-over-HTTPS может поддерживаться всяким DNS-сервером (резолвером), а не только некоторыми избранными, но такую поддержку должен настроить оператор сервера. Согласно публикации Microsoft, корпорация собирается ввести поддержку DNS-over-HTTPS в клиентские операционные системы, что позволит использовать защищённый канал для работы с DNS. Однако речь пока не идёт о том, что в системных настройках всем будет принудительно установлен некий центральный сервер (например, принадлежащий Microsoft), который поддерживает DNS-over-HTTPS. (Полностью, конечно, такой вариант, как бы ни хотелось, исключать нельзя.)

Технология касается только обмена данными между компьютером пользователя и резолвером DNS, сама по себе она не способна повлиять на прохождение IP-трафика, как-то: позволить обойти «блокировки по IP», изменить маршруты трафика или сделать нечто подобное, что могло бы повлиять на независимость национального сегмента Сети. Это просто метод защиты DNS-трафика от просмотра. Более того, если взглянуть на проблему с другой стороны, ничто, в принципе, не мешает массово внедрить независимые резолверы DNS с поддержкой DNS-over-HTTPS и DNS-over-TLS внутри Рунета (и это было бы очень хорошим шагом) — соответственно, пользователи, при желании, смогут подключаться к ним.

Но есть и аспекты, в которых полный переход на защищённую работу с DNS играет ключевую роль и меняет расстановку сил. Во-первых, эти технологии позволят противодействовать подмене DNS-ответов на транзитных узлах, что нейтрализует попытки простой блокировки доступа, работающей на уровне DNS и перехватывающей ответы других DNS-серверов. Во-вторых, продвинутые системы инспекции трафика не смогут просматривать пользовательские DNS-запросы и, таким образом, обнаруживать в пассивном режиме IP-адреса и доменные имена «подозрительных ресурсов». Но оба этих аспекта имеют смысл только в том случае, если пользователь настроил некоторые «внешние DNS-серверы» в качестве резолверов для операционной системы, а не использует резолверы интернет-провайдера (последние полностью провайдером контролируются).

AdGuard DNS: Как работает защита данных через DNS

Команда AdGuard инвестирует много времени и усилий в разработку решений защиты конфиденциальности пользователей, и многие пользователи ценят продукты AdGuard именно по этой причине. Самым большим вызовом для разработчиков AdGuard является не только обеспечение эффективной защиты, но и предоставление ее любому пользователю, независимо от используемого устройства.

Как раз для этого был создан AdGuard DNS – DNS-служба с акцентом на защиту конфиденциальности, которая блокирует трекеры, рекламные блоки где угодно, будь то стационарные компьютеры, мобильные устройства или смарт-ТВ и устройства «Интернета вещей». Официальный запуск AdGuard DNS состоялся в прошлом году, 18 декабря 2018 года, спустя два года после начала разработки службы.

Что такое DNS?

DNS – в образном смысле, это «адресная книга» Интернета. Каждый раз, когда вы открываете веб-сайт, отправляете электронное письмо или высылаете фотографию кота вашему другу, используемое вами приложение или браузер должно сопоставить имя домена (например, yahoo.com, легко запомнить, что не имеет смысла для компьютера) с IP-адресом, который фактически используют компьютеры. Для этого браузер или приложение отправляет специальный DNS-запрос DNS-преобразователю или резольверу. DNS-резольвер выполняет операцию преобразования доменного имени в IP-адрес и отправляет его обратно.

Схематическое изображение работы DNS

На самом деле система DNS является более сложной, но этой информации достаточно, чтобы получить базовое понимание. Обычно ваш интернет-провайдер (или оператор используемой сети) сам решает, какой DNS-преобразователь следует использовать.

Проблема конфиденциальности DNS

Заметили ли вы проблему на схеме выше? Действительно, случайное лицо, которое предоставляет вам доступ в Интернет, знает каждый домен, который вы посетили и когда происходил сеанс посещения. Одно из исследований на практике продемонстрировало, что модель поведения, полученная путем анализа исключительно данных DNS, позволила правильно идентифицировать 86% пользователей.

Это звучит не очень хорошо, особенно если учесть, сколько усилий многие люди прилагают для защиты своей конфиденциальности: использование HTTPS, VPN-сервисов, блокировщиков рекламы и др. Все эти активности можно отследить с помощью DNS с последующей монетизацией Интернет-провайдерами. Думаете, они не будут получать дополнительную прибыль при наличии соответствующей возможности?

DNS-трафик уязвим для злоумышленников

К счастью, существуют эффективное решение данной проблемы. Почти все устройства, которые позволяют вам выходить в Интернет, также дают возможность выбрать собственный преобразователь DNS. Какой выбрать? На рынке доступно много различных вариантов, но не все из них ставят в приоритет конфиденциальность. AdGuard предлагает сервис, который не только сохранит ваши действия в Интернете в тайне, но и предоставит дополнительные возможности защиты от сетевых угроз.

Давайте подробнее рассмотрим AdGuard DNS и выясним, почему это один из самых безопасных для вас вариантов на сегодняшний день.

Читать еще:  Яндекс почта безопасность

Тернистая дорога к безопасности

Выбор альтернативного DNS-резольвера является первым шагом для повышения конфиденциальности, но этого может быть недостаточно. Если никто не может иметь доступ к вашему DNS-трафику сейчас, это не значит, что никто не мог ранее. Протокол DNS совсем не новый, и тогда, когда он был разработан, стандарты конфиденциальности практически отсутствовали. В результате сегодня существует высокий риск того, что ваши DNS-запросы могут быть подслушаны или даже изменены злоумышленниками. Чтобы противостоять им, команда AdGuard приняла несколько действенных мер.

DNSCrypt

DNSCrypt стал первой попыткой обезопасить DNS-трафик от злоумышленников. Это специальный протокол, который зашифровывает связь между вашим устройством и DNS-сервером, защищая его от несанкционированного доступа и атак типа «человек посередине» (MITM-атаки). AdGuard DNS уже давно поддерживает эту технологию.

С AdGuard DNS ваш трафик защищен

Проблема DNSCrypt заключается в том, что протокол никогда не становился официальным стандартом и не получал документ RFC (документ с техническими спецификациями) в отличие от его альтернатив: DNS-over-HTTPS и DNS-over-TLS. Ожидается, что со временем DNSCrypt станет менее популярным и не получит особой поддержки на уровне операционной системе. К счастью, существуют и другие современные инструменты, которые не так широко распространены, но обеспечивают гораздо более высокий уровень безопасности и могут стать новыми стандартами конфиденциальности DNS в обозримом будущем.

DNS-over-TLS

DNS-over-TLS или DoT – протокол шифрования DNS-запросов и передачи по TLS-протоколу. DoT более надежен, чем DNSCrypt. Все больше и больше DNS сервисов поддерживают его, и AdGuard с гордостью вступает в их ряды.

Стоит упомянуть, что начиная с Android 9, устройства Android имеют встроенную поддержку DNS-over-TLS. Вы можете настроить свой смартфон или планшет на использование этого протокола в несколько нажатий без необходимости установки какого-либо дополнительного программного обеспечения.

DNS-over-HTTPS

DNS-over-HTTPS или DoH выполняет удаленное преобразование DNS по протоколу HTTPS. Это еще один безопасный способ защитить ваш трафик DNS от перехвата и подмены. Есть ли разница между DoT и DoH? Для обычного пользователя – практически никакой.

AdGuard DNS недавно получил поддержку DoH, которая выводит сервис на передний план защиты конфиденциальности. К сожалению, этот протокол все еще относительно новый, и способов применения его на вашем устройстве немного. Тем не менее, новая версия AdGuard для Android уже поддерживает эту опцию .

Другие меры защиты

Когда решена проблема с конфиденциальностью DNS, самое время подумать о других потенциальных угрозах. Ни для кого не секрет, что Интернет буквально кишит тысячами трекеров, которые следят за каждым вашим кликом, а затем используют эту информацию, чтобы нацелить вас на рекламу и создать цифровой отпечаток. Как с этим бороться? AdGuard DNS — это не только DNS-преобразователь, но и фильтр трафика. Всякий раз, когда ваше устройство отправляет «плохой» запрос для нужд рекламных блоков и трекеров, то вместо правильного IP-адреса DNS-сервер AdGuard ничего не вернет. Просто, но эффективно.

AdGuard DNS блокирует запросы к рекламным и отслеживающим доменам

Наконец, AdGuard фактически предоставляет два варианта службы DNS – «По умолчанию» и «Семейный». Единственная разница между ними заключается в том, что в режиме «Семейный» дополнительно блокируется доступ к любому контенту, не предназначенному для детей, и принудительно используется параметр Safe Search в браузерах, которые поддерживают данную функцию.

Подводим итоги

Как же настроить AdGuard DNS? Укажите DNS-сервера для вашего подключения или прямо на маршрутизаторе, используя нашу инструкцию.

DNS сервера

176.103.130.130 и 176.103.130.131 для серверов «По умолчанию»

176.103.130.132 и 176.103.130.134 для серверов «Семейный»

DNS-over-TLS

Используйте dns.adguard.com для серверов «По умолчанию» или dns-family.adguard.com для серверов «Семейный»

DNS-over-HTTPS

Используйте https://dns.adguard.com/dns-query для серверов «По умолчанию» или https://dns-family.adguard.com/dns-query для серверов «Семейный»

Помните, что AdGuard DNS – проект с открытым исходным кодом, как и все бесплатные продукты AdGuard. Компания считает чрезвычайно важным, чтобы услуги и продукты, которым вы доверяете защиту конфиденциальности данных, были максимально прозрачными и заслуживающими доверия. Чтобы просмотреть исходный код, узнать все о AdGuard DNS или даже оставить предложение, посетите репозиторий в GitHub.

Команда разработчиков надеется, что пользователям понравится AdGuard DNS. Они убеждены, что проект будет только расти. В будущем будет добавлено больше расположений серверов и новые дополнительные функции.

Защита DNS №1

DNS служба является достаточно критичным и важным компонентом
Интернета. Дело в том, что это служба нужна для того, чтобы пользователи могли общаться с узлами не по их ip адресам, которые собой представляют набор цифр, а по именам. С момента развития
Интернета, увеличилось и количество узлов в сети, поэтому появление DNS в принципе и следовало ожидать. Думаю, сейчас уже не стоит объяснять всю важность этой службы. Как я и сказал чуть выше, DNS сервера в сети отвечают за то, чтобы получить запросы от клиентских машин и соответствующим образом их обрабатывать, так же DNS сервер хранит так называемые зоны, в которых содержится вся необходимая информация. Клиенты могут запрашивать получение
IР адреса удаленного узла по имени и наоборот, все эти запросы посылаются к DNS серверу на 53 порт, по протоколу udp. Что все же происходит, когда этот запрос приходит на DNS сервер? Все очень просто, если DNS серверу не удалось найти соответствующих данных в своих зонах, то он может перенаправить этот запрос вышестоящему серверу, который может содержать необходимые данные. В данном случае это у нас рекурсивный запрос. Рекурсивный запрос – это запрос, на который DNS сервер обязан вернуть либо ответ запросившему компьютеру, либо сообщение об ошибке, так же DNS сервер берет на себя задачу опроса вышестоящих DNS серверов на предмет нужных данных. Существует и другой тип запросов, который чаще всего называется итеративным запросом. Итеративный запрос – это когда DNS сервер получает запрос и, если он не находит нужные данные у себя в зонах, он может вернуть в качестве ответа адреса другого DNS сервера, при этом предполагая, что клиент сделает соответствующий запрос к указанному DNS серверу в ответе.

Сейчас, когда мы с вами все же не много вспомнили принципы работы DNS сервера, мы можем обсудить вопросы его безопасности. Что нас интересует в первую очередь? Правильно
— отказоустойчивость. Что же можно сделать для повышения отказоустойчивости? Чаще всего в сети устанавливают вторичный DNS сервер, который полностью дублирует содержащуюся информацию на первичном DNS сервере. Такая практика встречается практически повсеместно, но многие не учитывают определенных факторов. Таких,
например, как нагрузка на каналы передачи данных. Допустим у нас в сети несколько тысяч клиентов и два DNS сервера, которые установлены в одном сетевом сегменте.
Все решили послать запрос на первичный DNS сервер, естественно уровень загруженности канала у нас резко возрастает или вообще
он отказывает. Что произойдет? Правильно, клиенты не получив ответ от первичного DNS сервера, будут посылать соответствующие запросы на вторичный, но вторичный у нас не сможет на них ответить, так как он их просто не получит, произойдет отказ в обслуживании. По этому очень важно располагать DNS сервера как можно «удачнее» в сети, то есть в разных сетевых сегментах, а еще лучше, если в разных подсетях. Казалась бы мелочь, но это мелочь очень существенна, особенно если вы крупный
Интернет-провайдер. Теперь хотелось бы поговорить по поводу самих запросов к DNS серверу. Первое: нам нужно, чтобы наш DNS сервер обслуживал компьютеры нашей сети, а не чужой. Тем самым мы снимаем еще и другие проблемы, такие как нагрузка нежелательных пользователей. Сделать это можно несколькими способами. Первый и самый желательный способ для подстраховки и снижения нагрузки на сервер это закрыть только входящие обращения по 53 порту по периметру сети. Но данный способ может не устраивать
Интернет-провайдера. А дело все в том, что
Интернет провайдер, как правило, имеет несколько каналов связи, проконтролировать соответствующие настройки
будет достаточно проблематично, но суть не в этом, суть в другом. Что если наш DNS сервер обслуживает какой-нибудь домен? Правильно, к нему тогда не смогут обратиться другие DNS серверы и получить соответствующую информацию, поэтому в данном случае ограничение по запросам из других сетей не стоит делать вообще или делать это очень и очень аккуратно. Второй способ это произвести соответствующие изменения в конфигурации DNS сервера. В качестве примера возьмем с вами BIND. Для того, чтобы разрешить производить работу только клиентам нашей сети, необходимо изменить добавить всего одну строчку в файле /etc/named.conf. Открыв этот самый файл, мы с вами находим в начале файла раздел options и пишем туда следующие:

Читать еще:  Чистка ноутбука от вирусов программа

Где 213.48.57.70 идентификатор нашей сети, 24 код по CIDR который в свою очередь соответствует маске подсети 255.255.255.0, а localhost сам сервер.

Вы, наверное, часто встречали в Интернете информацию, о том, что все же лучше отключать рекурсивные запросы на DNS серверах. Это действительно так, так как чаще всего при организации DDOS атак используют рекурсию, да и зачем нагружать DNS сервер ненужной работой, если часть функций может выполнить и сам клиент? Правильно
— не зачем. Как исправить? В случае с BIND’ом опять открываем файл named.conf
и в разделе options добавляем следующую строчку:

Если вы все же страдает полной паранойей, то вы можете значение localhost заменить на none, что приведет к полному отключению возможности обработки рекурсивных запросов, даже если источник этих запросов сам сервер. В данном случае тогда
и спуффинг самого DNS сервера не поможет. Вроде бы, когда мы окончательно разобрались с запросами, можно перейти и к другой части статьи, но все же в конце статьи я дам еще одну маленькую рекомендацию по этому поводу.

Битва за данные пользователей: зачем нужно шифровать DNS-запросы


Специалисты по обеспечению конфиденциальности и безопасности находятся в центре публичной борьбы за будущее шифрования трафика в интернете. В сентябре кабельные компании и другие представители телекоммуникационной отрасли в США направили в Конгресс письмо с протестом против планов Google по шифрованию трафика системы доменных имен (DNS) в браузере. В этом месяце Mozilla отправила в Конгресс собственное письмо, в котором просила законодателей не рассматривать этот протест, поскольку он основан на «фактических неточностях».

Речь идет о том, как следует шифровать DNS-трафик — сетевые запросы, которые преобразуют понятные людям доменные имена (адреса сайтов) в IP-адреса серверов. Когда пользователь вводит доменное имя в браузере, тот запрашивает у ближайшего указанного в настройках DNS-сервера IP-адрес, связанный с этим доменным именем.

По умолчанию эти запросы и ответы сервера отправляются по сети в виде обычного текста, что означает, что кто-то может перехватить их и перенаправить пользователя в другое место назначения. Простые текстовые DNS-запросы также позволяют администраторам сети видеть, на какие сайты заходят пользователи: фактические действия могут быть зашифрованы, но и такие знания могут предоставить ценную информацию, например, для рекламодателей.

Шифрование DNS гарантирует, что «браузер общается с тем, с чем вы хотите взаимодействовать, а не с тем, куда вас зовут вредоносные программы», — говорит Тим Эйприл, главный архитектор сетевой компании Akamai.

Никто не спорит с тем, что DNS должен быть зашифрован. Третьи стороны не должны иметь возможность перехватывать и перенаправлять пользователей на сторонние сайты, на которых могут быть размещены вредоносные программы или поддельные формы авторизации. Разногласия заключатся лишь в том, как это шифрование должно быть сделано.

Существует два варианта: так называемые DNS поверх TLS и DNS поверх HTTPS. Первый подчеркивает безопасность и дает администраторам сетей больше контроля, а второй подчеркивает конфиденциальность пользователей. С точки зрения удобства использования пользователи не заметят различий с любым из этих подходов, чего нельзя сказать о системных администраторах.

Два способа шифрования

Современные сети полагаются на протокол защиты транспортного уровня (TLS) для безопасного обмена данными, например, для просмотра веб-страниц, передачи файлов, VPN-подключений, сеансов удаленного рабочего стола и передачи голоса по IP-телефонии. Одна сторона соединения, обычно сервер, имеет сертификат с цифровой подписью, выданный доверенным центром сертификации. Другая сторона соединения, обычно клиент, использует сертификаты для проверки того, с кем он обменивается данными.

Поскольку протокол TLS уже широко используется для обеспечения конфиденциальности, аутентификации и целостности данных, расширение протокола для работы с DNS является вполне логичным. DNS поверх TLS (IETF RFC 7858) определяет, как DNS-пакеты будут шифроваться с помощью TLS и передаваться по широко используемому протоколу управления передачей (TCP).

Читать еще:  Макрос отключен по соображениям безопасности

По умолчанию DNS проходит через порт 53 по протоколу TCP или UDP. При использовании DNS поверх TLS все зашифрованные пакеты отправляются через порт 853. Большинство общедоступных DNS-серверов, включая Cloudflare, Quad9 и Google, уже поддерживают DNS поверх TLS, и компании, использующие собственную DNS-инфраструктуру, также могут использовать такое шифрование.

Google включил поддержку DNS поверх TLS в Android Pie (Android 9), чтобы пользователи могли настраивать шифрование DNS как для Wi-Fi, так и для мобильной сети, и многие приложения и устройства уже умеют работать с этой опцией.

«Мы решили проблему, добавив DNS к TLS», — сказал Пол Викси, изобретатель DNS и генеральный директор Farsight Security. Он также признает, что такое решение не является «веб-дружественным» в том смысле, что нет простого пользовательского интерфейса для включения этой функции.

DNS поверх HTTPS (IETF RFC8484) в значительной степени разработан с оглядкой на принципы работы современного интернета, поскольку он вбрасывает все пакеты данных в поток HTTPS вместе с другим зашифрованным веб-трафиком. В отличие от своего конкурента, DNS поверх HTTPS не шифрует отдельные запросы, а вместо этого пропускает их через зашифрованный туннель между клиентом и сервером.

Поскольку соединение использует HTTPS и HTTP/2, все пакеты выглядят одинаково. Любой, кто отслеживает порт 443 — стандартный порт HTTPS — не сможет идентифицировать DNS-запросы из всего остального веб-трафика.

Плюсы и минусы каждого подхода

Для сторонников конфиденциальности DNS через TLS недостаточно хорош, потому что любой, кто контролирует сеть, будет знать, что любая активность на 853-ем порту связана с этим DNS. Хотя наблюдатель не будет знать фактическое содержание запроса, поскольку и ответ, и запрос зашифрованы, тот факт, что сетевой администратор или провайдер будут знать, что есть такая активность, уже может привести к последствиям для пользователя (в худшем случае этот порт может быть вообще закрыт). Хотя DNS поверх TLS безопасен, он не так удобен с точки зрения конфиденциальности, как DNS поверх HTTPS.

Еще один недостаток DNS поверх TLS заключается в том, что разработчикам программного обеспечения и производителям устройств необходимо внести изменения, чтобы их приложения и оборудование поддерживали этот протокол. И если такой поддержки нет, даже если указанный DNS-сервер может работать с таким шифрованием, оно не будет защищать данные пользователя.

DNS поверх HTTPS более демократичен, поскольку любой пользователь, использующий поддерживаемый веб-браузер, автоматически получает шифрование DNS. DNS поверх HTTPS лишает любые третьи стороны — в том числе поставщиков интернет-услуг и правительственные учреждения — возможности просматривать информацию о том, какие сайты посещает пользователь. Это именно то, что хотят защитники конфиденциальности, но это противоположно тому, что нужно сетевым администраторам.

Конфиденциальность против безопасности

DNS поверх HTTPS возводит конфиденциальность в абсолют, но создатели приложений родительского контроля, антивирусных программ, корпоративных брандмауэров и других сетевых инструментов не разделяют эту идеологию. Включение DNS поверх HTTPS по умолчанию в веб-браузере означает, что все DNS-запросы передаются на указанный DNS-сервер, который может не являться собственным DNS-сервером организации или провайдера.

Mozilla объявила, что DNS поверх HTTPS будет использоваться по умолчанию для пользователей Firefox в Соединенных Штатах, и это изменение в настоящее время активно внедряется. Firefox автоматически передает весь DNS-трафик популярному серверу Cloudflare 1.1.1.1 и игнорирует существующие настройки DNS пользователя. Это обходит все связанные с DNS сетевые правила фильтрации, в том числе позволяет попасть на сайты, доступ к которым блокируется по DNS.

Google также включил DNS поверх HTTPS для пользователей Chrome, но тут его принцип работы немного отличается, поскольку браузер по умолчанию использует DNS поверх HTTPS только в том случае, если у пользователя есть служба, совместимая с DNS поверх HTTPS.

Microsoft, как обычно, хочет усидеть на двух стульях одновременно: с одной стороны, компания планирует поддерживать DNS поверх HTTPS в Windows, с другой — хочет дать системным администраторам некоторый контроль.

Эйприл считает, что шифрование DNS — это «разумное ограничения доступа» к плохим ресурсам, но с ним нужно быть осторожнее. Провайдеры частенько блокируют имена хостов, используемые Wannacry и другими вредоносными программами, и временами перенаправляют пользователей, пытающихся получить доступ к вредоносным или заблокированным сайтам. Администраторы общедоступных сетей Wi-Fi модифицируют DNS-запросы, чтобы сначала загружалась страница авторизации для новых пользователей. DNS поверх HTTPS ломает все эти настройки.

Отчасти поэтому Mozilla не включает DNS поверх HTTPS для пользователей Firefox в Соединенном Королевстве, так как там закон требует от интернет-провайдеров блокировать доступ к нелегальным веб-сайтам, таким как те, которые связаны с детской порнографией.

DNS поверх HTTPS против DNS поверх TLS — это еще одна разновидность борьбы за данные о просмотре веб-страниц пользователем и за то, кто получит доступ к ним. DNS-запросы от Firefox будут отправляться в Cloudflare, что означает, что Cloudflare будет иметь доступ к огромному количеству данных DNS. По словам Викси, технологические компании, которые управляют централизованными DNS-серверами, такие как Cloudflare и Google, в конечном итоге получат выгоду от DNS поверх HTTPS, поскольку именно они будут получать информацию о том, что люди просматривают в интернете.

Сторонники конфиденциальности считают, что не провайдеры, а сами пользователи должны отвечать за то, как они попадают на сайты в интернете. Но решение Mozilla заставляет пользователей Firefox использовать Cloudflare независимо от их собственных предпочтений.

Большинство пользователей не заметят никакой разницы, когда шифрованный DNS станет стандартным, что уже произошло для пользователей Chrome. Для компаний и интернет-провайдеров социально-сознательный, ориентированный на пользователя подход вынуждает идти на компромисс: ценой повышения конфиденциальности является снижение безопасности.

Реальность современного интернета заключается в том, что интернет-провайдеры и компании играют определенную роль в предотвращении угроз для пользователей. В идеале веб-браузеры должны позволять пользователям выбирать, следует ли использовать DNS поверх TLS или DNS поверх HTTPS, а также предоставлять пользователям возможность контролировать, какого поставщика DNS использовать.

Ссылка на основную публикацию
Adblock
detector