Зачем нужно отключать в сафари dns
Что это вообще значит? Мой iPhone сломался?
Нет, ваш смартфон не сломался.
Так в чём же дело? Всё просто!
Предупреждение о незащищённом подключении означает лишь то, что между браузером Safari и посещаемым сайтом не удаётся создать безопасное соединение.
Vivaldi
Представитель Vivaldi сказал, что поддержка DoH связана с реализацией Chrome. Пользователи могут включить её, перейдя по следующему URL:
Однако поскольку DoH в Vivaldi работает так же, как в Chrome, он не будет шифровать DNS-запросы, если пользователь использует DNS-сервер, указанный в ОС, и не поддерживающий шифрование.
Скорее всего, придётся добавить в настройки DNS вашей ОС один из серверов, поддерживающий DoH, чтобы эта функция заработала в Vivaldi, и использовать его постоянно. Мы смогли добиться этого, прописав в настройках DNS-сервер 1.1.1.1.
Представитель Vivaldi сказал, что в будущем поддержка DoH в браузере может поменяться, в зависимости от того, как Google будет изменять поддержку протокола в Chromium.
Дело почти дошло до «замены шлюза с встроенным контроллером точек доступа», управляющего десятками точек доступа, но ведь у Андроидов и Windows-устройств всё в порядке было.
В статье излагаются результаты проведенных исследований, перечисляются все танцы с бубном и перепробованные способы устранения проблемы. Печально, но решение, устроившее бы всех, так и не было найдено. Может быть после прочтения кому-то придет в голову что можно сделать. А тому, кто изложит в комментариях реальный фикс, который решит проблему на моём оборудовании, будет подарок: функциональный и стильный рюкзак от Zyxel.
Мои предыдущие статьи (спойлер).
В конце текста информация обо мне.
Итак, если разблокировать экран, телефон снова ищет Wi-Fi точку доступа и подключается к ней, если стояла галочка «Автоподключение», которая по дефолту не стоит при первом подключении к Wi-Fi. Необходимо вручную активировать её.
Рис.1 - Галочка для автоподключения к Wi-Fi.
Да сколько же это будет продолжаться?
Не оставлять же телефон с постоянно включённым экраном? Поиск в интернете предложил много сайтов и видеороликов. Рекомендации в основном были такие:
«Помощь Wi-Fi» отключить;
эксперименты с настройками GPS, конфиденциальностью;
эксперимент с временами аренды DHCP.
Это не помогло. Ещё были рекомендации, которые совпали с рекомендациями техподдержки Apple после официального обращения к ним:
жёсткая перезагрузка (кнопки ДОМОЙ+ВКЛ/ВЫКЛ или др. комбинации);
обновление ПО шлюза (роутера);
сброс шлюза и с повторной настройкой с нуля;
«Сбросить настройки сети» на телефоне.
Перечисленные рекомендации, не помогли, кроме последней. Она помогла на пару дней, потом проблема снова повторялась. Далее были ещё рекомендации:
обновление версии iOS до актуальной;
Обновление iOS реально помогло, но потом редко у некоторых проблема стала повторяться. Хозяин телефона «Сбросить настройки сети» отказывался и такое всем не предложишь.
Самое удивительное было то, что когда выходит новая версия iOS, нынешняя исправная версия начинает отваливаться от Wi-Fi. Раньше же нормально работало на этой же версии! Получается, что как версия iOS устаревает, телефон будет отваливаться от Wi-Fi.
Как быть тогда с пенсионерами Apple 5s; 6 у которых последняя версия iOS 12.5.5? Эти модели тоже отваливались от Wi-Fi.
Следующая рекомендация такая была:
замените! шлюз или точку доступа.
Звучит как приговор. Домашний роутер ладно, там одна железка за 3 тыс.рублей и поменяться с кем-нибудь на время можно.
Как быть с шлюзом с аппаратным контроллером, который заведует десятками точек доступа? В этот комплекс столько денег, нервных клеток, переговоров с интеграторами, времени было вложено. Один только шлюз стоит 100 тыс.рублей, а если Cisco за 1 млн рублей был бы? Ну да, конечно, денег молча дали, заказал шлюз, привезли, поменял, ага, размечтались. 128 штук точек доступа тоже нужно поменять? Большинство на потолках, высотой 3-9 м, со стремянки не достанешь.
И руководству что говорить? Что в проекте ошиблись вендором, нужно его поменять на другого вендора ради телефонов Apple?
Поэтому вариант смены шлюза и точек доступа был неприемлемым, но давайте проверим детально, а верна ли эта рекомендация? Может поможет или АйФоны опять будут отваливаться?
Поэтому пришлось собрать АйФоны моделей iPhone 4s (iOS 9.3.5), 5s (iOS 12), 6 (iOS 10) и 7 (iOS 11 и 13), звал коллег из других подразделений потестить их АйФоны, вкусняшки покупал в знак благодарности. Всё это тестировал на свободном резервном шлюзе Zyxel UAG5100 с управляемой точкой доступа Zyxel NWA5121-NI, сброшенные в дефолтное состояние, настраивал шлюз небольшими шагами с обязательной проверкой поведения АйФонов, после какой настройки начнут отваливаться АйФоны от Wi-Fi.
Таблица 1 - Поиск причины отключения АйФона от Wi-Fi.
№ шага
Внесённая настройка
iPhone 4s (iOS 9.3.5), 5s (iOS 12), 6 (iOS 10) и 7 (iOS 11 и 13) и другие отключились от Wi-Fi?
WAN порт, DHCP в LAN подсети и SSID “Test”
Время аренды DHCP
Радиоканалы, мощность, балансировка SSID
Привязка IP/MAC, изоляция L2
BWM; ограничение скоростей в SSID; Intra-BSS
Включение Captive Portal (портал авторизации)
ДА, после ввода ваучера
Выключение Captive Portal (портал авторизации)
Включение Captive Portal (портал авторизации)
ДА, после ввода ваучера
Внесение MAC-адресов АйФонов в белый список, чтобы не запрашивать у них авторизацию
Значит после пройденной авторизации через Captive Portal (могут называться как портал авторизации или веб-аутентификация) АйФон отваливается от Wi-Fi.
Сбрасываю ещё раз конфиг UAG5100, чтобы исключить остальные взаимосвязанные настройки, оставив критические. Если проблема повторится, то попробую другие точки доступа.
Таблица 2 - Сравнение поведение АйФонов с различными точками доступа Wi-Fi на этом же шлюзе из таблицы 1, но с нуля заново настроенный по таблице 2.
№ шага
Внесённая настройка
iPhone 4s (iOS 9.3.5), 5s (iOS 12), 6 (iOS 10) и 7 (iOS 11 и 13) и другие отключились от Wi-Fi?
WAN порт, DHCP в LAN подсети и SSID «Test»
Включение Captive Portal (портал авторизации)
Выключение Captive Portal (портал авторизации)
Точку доступа меняю на Zyxel NWA5123-AC с SSID «Test2»
Включение Captive Portal
Выключение Captive Portal
Точку доступа меняю на автономную D-Link DAP-2690 с SSID «Test3»
Включение Captive Portal
Выключение Captive Portal
Точку доступа меняю на домашний однодиапазонный роутер Zyxel Keenetic 4G в режиме точки доступа, чтобы SSID «Test4» работал только на 2.4 ГГц
Включение Captive Portal
Выключение Captive Portal
Точку доступа меняю на Элтекс WEP-2ac «Test5»
Включение Captive Portal
Выключение Captive Portal
Возвращаю точку доступа Zyxel NWA5121-NI в режиме автономной (заранее сбросив её конфиг)
Включение Captive Portal
Выключение Captive Portal
Выключаю DHCP на шлюзе и установил статический IP на АйФонах
Включение Captive Portal
Выключение Captive Portal
Переключаю Zyxel NWA5121-NI в управляемый режим
Включение Captive Portal
В таблицах 1 и 2 Captive Portal тестировал со встроенным сервисом по ваучерам, потом тестировал с пятью внешними сервисами авторизаций, проблема оставалась такая же, iPhone отваливается от Wi-Fi.
Рис.2 - Поведение АйФона по логам шлюза с DHCP.
Меняю шлюз на другие на тестовом стенде.
Таблица 3 - Проверка поведения АйФонов, подключённых к Wi-Fi после прохождения авторизации через Captive Portal на различных шлюзах.
Наименование шлюза с настройками как из таблицы 2 (1-я и 2-я строки).
iPhone 4s (iOS 9.3.5), iPhone 5s (iOS 12), 6 (iOS 10) и 7 (iOS 11 и 13) и другие отключились от Wi-Fi?
Не шлюз, но с функционалом Captive Portal. Программный комплекс Элтекс SoftWLC
Шлюз Элтекс ESR-20
В таблице 3 проверялись встроенные и внешние сервисы авторизации, поведение не поменялось, iPhone отключается от Wi-Fi.
Прошу обратить внимание, во всех трёх таблицах проблем с Андроидами и Windows не было. Там всё хорошо.
Спросил у знакомого, любителя Микротиков, насчёт АйФонов. Ответил, что у него тоже самое, iPhone отваливаются от Wi-Fi.
Узнаем у Гугла, как у заокеанских коллег на родине АйФонов дела обстоят? Первым предложил ссылку на форум Микротиков
Рис.3 - Скриншот с форума Микротика с темой про iPhone, отключающиеся от хотспотов. Рис.4 - Перевод текста на рис.3.
Но больше волнуют Cisco и Aruba, земляки АйФонов, всё-таки в одной стране находятся, может у них получше с этой проблемой.
Вот на форуме Арубы
Рис.5 - Скриншот с форума Арубы с темой про iOS, отключающихся от Wi-Fi (с переведённым текстом).
Там на форуме Cisco
Рис.6 - Скриншот с форума Cisco с темой про iPhone.
Перевод текста (рис.6, 7 и 8):
Рис.7 - Перевод текста. Рис.8 - Перевод текста (продолжение рис.7). Рис.9 - Перевод текста (продолжение рис.8).
А вот и реакция гостей в этой же теме «iPhone silent disconnect issue in guest wireless network.» и как много точек доступа и гостей у них, 6000! точек доступа!
Рис.10 - Скриншот с форума Cisco с переводом.
напоследок видео из этой же темы.
Действительно так и ведут себя АйФоны в гостевых сетях с Captive Portal. Даже добавить нечего.
Итог: дочитав вышеуказанные ссылки на форумы, проблему так и не устранили. На американском оборудовании тоже американские АйФоны отваливаются и обратите внимание на даты создания тем. Проблема годами сохраняется. У коллеги iPhone 12 на прошлой неделе обновился на самую последнюю версию iOS 15 и стал отваливаться от Wi-Fi, а на предыдущем обновлении всё нормально было.
Вывод: проблема в устройствах Apple, но не в шлюзах и точках доступа, поэтому рекомендация «смена шлюза и точек доступа» явно не сработала, не помогла и, к огромному счастью, ей следовать не придётся.
В общем, отключение Captive Portal действительно помогает, всё отлично работает, но его отключать нельзя (постановления Правительства РФ №758 от 31 июля 2014 года и №801 от 12 августа 2014 года). Ищем варианты подружить Apple с Captive Portal.
Методом тыка выявил , что есть шанс немного помочь гостям двумя способами, прошедшие авторизацию:
Способ 1 (для чайников):
2. Заново подключиться к Wi-Fi
и устройство не будет отключаться от Wi-Fi до истечения срока авторизации. Когда истечёт авторизация, страница авторизации сама не выскочит и гость впадает в ступор, почему нет интернета и как пройти авторизацию, если страница авторизации не появляется?
Объяснение, с какой проблемой сталкиваются чайники:
Поэтому, чтобы страница авторизации появилась как прежде, необходимо:
4. Заново подключиться к Wi-Fi;
5. Появится страница авторизации, но после прохождения авторизации по устройство снова будет отключаться от Wi-Fi как прежде. Повторить пункт 1 и 2.
И так каждый раз, пока не поставят последнюю версию iOS (не является 100% гарантией устранения проблем).
Способ 2 (для продвинутых):
2. Заново подключиться к Wi-Fi
и устройство не будет отключаться от Wi-Fi до истечения срока авторизации. Когда истечёт авторизация, страница авторизации сама не выскочит.
4. Пройти авторизацию как обычно и всё будет нормально работать, АйФоны не отключаются от Wi-Fi. При истечении авторизации повторить пункт 3.
Не совсем удобные способы, слишком много действий нужно, чтобы всё нормально заработало и всем не объяснишь, мануалы никто не читает.
Дальше ещё одно исследование с неуспешным концом. Яндекс подсказал ещё эту статью. Цитирую оттуда кусочек текста
Исходя из этого, попробуем занести эту ссылку в белый список, которые можно пропускать в интернет без авторизации.
Это не помогло, АйФоны отключаются от Wi-Fi как обычно, хотя на ссылку удаётся зайти без авторизации.
Всё на сегодня. Мне самому очень нравятся АйФоны, несмотря на цену, но эта вот болячка с Wi-Fi через авторизацию портит всё.
А как у вас? Удалось ли кому решить проблему? Поделитесь, пожалуйста, в комментариях. Предлагайте решение, я проверю у себя и если всё заработает - рюкзак ваш.
Устройства, где нужно пофиксить проблему:
Zyxel UAG5100 (несильно отличается от шлюзов серий ZyWALL, USG);
Zyxel VPN300 (несильно отличается от шлюзов серии USG Flex; ATP);
Точки доступа любые, они не влияют на Captive Portal.
Об авторе:
Кто я? Меня зовут Александр. 16 лет профессионально занимаюсь СКС и сетевым оборудованием. Больше времени провожу с СКС (монтаж, обслуживание), чем с настройкой сетевого оборудования, поэтому на настройки времени особо нет, но получил много опыта работы с сетевым оборудованием различных вендоров. Приветствую простоту и дружелюбность конфигурирования/мониторинга сетевого оборудования, ответственность вендора за качество выпускаемой продукции и готовность исправлять недостатки, чтобы не тормозили сдачу новых проектов в назначенные сроки. Меня можно встретить и лично пообщаться в телеграме - @NSanchez13, так что, если будут вопросы, комментарии, мнения – милости прошу.
Шифрование трафика между вашим устройством и DNS-сервисом помешает посторонним лицам отслеживать трафик или подменить адрес
Смерть сетевого нейтралитета и ослабление правил для интернет-провайдеров по обработке сетевого трафика вызвали немало опасений по поводу конфиденциальности. У провайдеров (и других посторонних лиц, которые наблюдают за проходящим трафиком) уже давно есть инструмент, позволяющий легко отслеживать поведение людей в интернете: это их серверы доменных имен (DNS). Даже если они до сих пор не монетизировали эти данные (или не подменяли трафик), то наверняка скоро начнут.
«Открытые» DNS-сервисы позволяют обходить сервисы провайдеров ради конфиденциальности и безопасности, а кое в каких странах — уклоняться от фильтрации контента, слежки и цензуры. 1 апреля (не шутка) компания Cloudflare запустила свой новый, бесплатный и высокопроизводительный DNS-сервис, предназначенный для повышения конфиденциальности пользователей в интернете. Он также обещает полностью скрыть DNS-трафик от посторонних глаз, используя шифрование.
Названный по своему IP-адресу, сервис 1.1.1.1 — это результат партнёрства с исследовательской группой APNIC, Азиатско-Тихоокеанским сетевым информационным центром, одним из пяти региональных интернет-регистраторов. Хотя он также доступен как «открытый» обычный DNS-резолвер (и очень быстрый), но Cloudflare ещё поддерживает два протокола шифрования DNS.
Хотя и разработанный с некоторыми уникальными «плюшками» от Cloudflare, но 1.1.1.1 — никак не первый DNS-сервис с шифрованием. Успешно работают Quad9, OpenDNS от Cisco, сервис 8.8.8.8 от Google и множество более мелких сервисов с поддержкой различных схем полного шифрования DNS-запросов. Но шифрование не обязательно означает, что ваш трафик невидим: некоторые службы DNS с шифрованием всё равно записывают ваши запросы в лог для различных целей.
Cloudflare пообещал не журналировать DNS-трафик и нанял стороннюю фирму для аудита. Джефф Хастон из APNIC сообщил, что APNIC собирается использовать данные в исследовательских целях: диапазоны 1.0.0.0/24 и 1.1.1.0/24 изначально были сконфигурированы как адреса для «чёрного» трафика. Но APNIC не получит доступ к зашифрованному трафику DNS.
Для пользователей подключить DNS-шифрование не так просто, как изменить адрес в настройках сети. В настоящее время ни одна ОС напрямую не поддерживает шифрование DNS без дополнительного программного обеспечения. И не все сервисы одинаковы с точки зрения софта и производительности.
Как работает DNS
Есть много причин для лучшей защиты DNS-трафика. Хотя веб-трафик и другие коммуникации могут быть защищены криптографическими протоколами, такими как Transport Layer Security (TLS), но почти весь трафик DNS передаётся незашифрованным. Это означает, что ваш провайдер (или кто-то другой между вами и интернетом) может регистрировать посещаемые сайты даже при работе через сторонний DNS — и использовать эти данных в своих интересах, включая фильтрацию контента и сбор данных в рекламных целях.
Как выглядит типичный обмен данными между устройством и DNS-резолвером
«У нас есть проблема “последней мили” в DNS, — говорил Крикет Лю, главный архитектор DNS в компании Infoblox, которая занимается информационной безопасностью. — Большинство наших механизмов безопасности решают вопросы коммуникаций между серверами. Но есть проблема с суррогатами резолверов на различных операционных системах. В реальности мы не можем их защитить». Проблема особенно заметна в странах, где власти более враждебно относятся к интернету.
Наиболее очевидный способ уклонения от слежки — использование VPN. Но хотя VPN скрывают содержимое вашего трафика, для подключения к VPN может потребоваться запрос DNS. И в ходе VPN-сеанса запросы DNS тоже могут иногда направляться веб-браузерами или другим софтом за пределы VPN-тоннеля, создавая «утечки DNS», которые раскрывают посещённые сайты.
Однако эта опция защиты недоступна массовому пользователю. Ни один из этих протоколов нативно не поддерживается ни одним DNS-резолвером, который идёт в комплекте с ОС. Все они требуют установки (и, вероятно, компиляции) клиентского приложения, которое действует как локальный «сервер» DNS, ретранслируя запросы, сделанные браузерами и другими приложениями вверх по течению к безопасному провайдеру DNS по вашему выбору. И хотя две из трёх данных технологий предлагаются на роль стандартов, ни один из проверенных нами вариантов пока не представлен в окончательном виде.
Поэтому если хотите погрузиться в шифрование DNS, то лучше взять для DNS-сервера в домашней сети Raspberry Pi или другое отдельное устройство. Потому что вы наверняка обнаружите, что настройка одного из перечисленных клиентов — это уже достаточно хакерства, чтобы не захотеть повторять процесс заново. Проще запросить настройки DHCP по локальной сети — и указать всем компьютерам на одну успешную установку DNS-сервера. Я много раз повторял себе это во время тестирования, наблюдая падение одного за другим клиентов под Windows и погружение в спячку клиентов под MacOS.
Сообщество DNSCrypt пыталось сделать доступный инструмент для тех, кто не обладает навыками работы в командной строке, выпустив программы DNSCloak (слева) под iOS и Simple DNSCrypt (справа) под Windows
Для полноты картины в исторической перспективе начнём обзор с самой первой технологии шифрования DNS — DNSCrypt. Впервые представленный в 2008 году на BSD Unix, инструмент DNSCrypt изначально предназначался для защиты не от прослушки, а от DNS-спуфинга. Тем не менее, его можно использовать как часть системы обеспечения конфиденциальности — особенно в сочетании с DNS-сервером без логов. Как отметил разработчик DNSCrypt Фрэнк Денис, гораздо больше серверов поддерживают DNSCrypt, чем любой другой вид шифрования DNS.
«DNSCrypt — это немного больше, чем просто протокол, — говорит Фрэнк Денис. — Сейчас сообщество и активные проекты характеризуют его гораздо лучше, чем мой изначальный протокол, разработанный в выходные». Сообщество DNSCrypt создало простые в использовании клиенты, такие как Simple DNSCrypt для Windows и клиент для Apple iOS под названием DNS Cloak, что делает шифрование DNS доступнее для нетехнических людей. Другие активисты подняли независимую сеть приватных DNS-серверов на основе протокола, помогающего пользователям уклониться от использования корпоративных DNS-систем.
«DNSCrypt — это не подключение к серверам конкретной компании, — сказал Денис. — Мы призываем всех поднимать собственные сервера. Сделать это очень дёшево и легко. Теперь, когда у нас есть безопасные резолверы, я пытаюсь решить задачу фильтрации контента с учётом конфиденциальности».
Для тех, кто хочет запустить DNS-сервер с поддержкой DNSCrypt для всей своей сети, лучшим клиентом будет DNSCrypt Proxy 2. Старая версия DNSCrypt Proxy по-прежнему доступна как пакет для большинства основных дистрибутивов Linux, но лучше загрузить бинарник новой версии непосредственно с официального репозитория на GitHub. Есть версии для Windows, MacOS, BSD и Android.
Опыт сообщества DNSCrypt по защите конфиденциальности воплощён в DNSCrypt Proxy. Программа легко настраивается, поддерживает ограничения по времени доступа, шаблоны для доменов и чёрный список IP-адресов, журнал запросов и другие функции довольно мощного локального DNS-сервера. Но для начала работы достаточно самой базовой конфигурации. Есть пример файла конфигурации в формате TOML (Tom's Obvious Minimal Language, созданный соучредителем GitHub Томом Престоном-Вернером). Можете просто переименовать его перед запуском DNSCrypt Proxy — и он станет рабочим файлом конфигурации.
По умолчанию прокси-сервер использует открытый DNS-резолвер Quad9 для поиска и получения с GitHub курируемого списка открытых DNS-сервисов. Затем подключается к серверу с самым быстрым откликом. При необходимости можно изменить конфигурацию и выбрать конкретный сервис. Информация о серверах в списке кодируется как «штамп сервера». Он содержит IP-адрес поставщика, открытый ключ, информацию, поддерживает ли сервер DNSSEC, хранит ли провайдер логи и блокирует ли какие-нибудь домены. (Если не хотите зависеть от удалённого файла при установке, то можно запустить «калькулятор штампов» на JavaScript — и сгенерировать собственный локальный статичный список серверов в этом формате).
Для своего тестирования DNSCrypt я использовал OpenDNS от Cisco в качестве удалённого DNS-сервиса. При первых запросах производительность DNSCrypt оказалась немного хуже, чем у обычного DNS, но затем DNSCrypt Proxy кэширует результаты. Самые медленные запросы обрабатывались в районе 200 мс, в то время как средние — примерно за 30 мс. (У вас результаты могут отличаться в зависимости от провайдера, рекурсии при поиске домена и других факторов). В целом, я не заметил замедления скорости при просмотре веб-страниц.
С другой стороны, DNSCrypt для шифрования не полагается на доверенные центры сертификации — клиент должен доверять открытому ключу подписи, выданному провайдером. Этот ключ подписи используется для проверки сертификатов, которые извлекаются с помощью обычных (нешифрованных) DNS-запросов и используются для обмена ключами с использованием алгоритма обмена ключами X25519. В некоторых (более старых) реализациях DNSCrypt есть условие для сертификата на стороне клиента, который может использоваться в качестве схемы управления доступом. Это позволяет им журналировать ваш трафик независимо от того, с какой IP-адреса вы пришли, и связывать его с вашим аккаунтом. Такая схема не используется в DNSCrypt 2.
С точки зрения разработчика немного сложно работать с DNSCrypt. «DNSCrypt не особенно хорошо документирован, и не так много его реализаций», — говорит Крикет Лю из Infoblox. На самом деле мы смогли найти только единственный клиент в активной разработке — это DNSCrypt Proxy, а OpenDNS прекратил поддерживать его разработку.
Интересный выбор криптографии в DNSCrypt может напугать некоторых разработчиков. Протокол использует Curve25519 (RFC 8032), X25519 (RFC 8031) и Chacha20Poly1305 (RFC 7539). Одна реализация алгоритма X24419 в криптографических библиотеках Pyca Python помечена как «криптографически опасная», потому что с ней очень легко ошибиться в настройках. Но основной используемый криптографический алгоритм Curve25519, является «одной из самых простых эллиптических кривых для безопасного использования», — сказал Денис.
Разработчик говорит, что DNSCrypt никогда не считался стандартом IETF, потому что был создан добровольцами без корпоративной «крыши». Представление его в качестве стандарта «потребовало бы времени, а также защиты на заседаниях IETF», — сказал он. «Я не могу себе этого позволить, как и другие разработчики, которые работают над ним в свободное время. Практически все ратифицированные спецификации, связанные с DNS, фактически написаны людьми из одних и тех же нескольких компаний, из года в год. Если ваш бизнес не связан с DNS, то действительно тяжело получить право голоса».
TLS стал приоритетом для CloudFlare, когда понадобилось усилить шифрование веб-трафика для защиты от слежки
У DNS по TLS (Transport Layer Security) несколько преимуществ перед DNSCrypt. Во-первых, это предлагаемый стандарт IETF. Также он довольно просто работает по своей сути — принимает запросы стандартного формата DNS и инкапсулирует их в зашифрованный TCP-трафик. Кроме шифрования на основе TLS, это по существу то же самое, что и отправка DNS по TCP/IP вместо UDP.
Существует несколько рабочих клиентов для DNS по TLS. Самый лучший вариант, который я нашел, называется Stubby, он разработан в рамках проекта DNS Privacy Project. Stubby распространяется в составе пакета Linux, но есть также версия для MacOS (устанавливается с помощью Homebrew) и версия для Windows, хотя работа над последней ещё не завершена.
Хотя мне удалось стабильно запускать Stubby на Debian после сражения с некоторыми зависимостями, этот клиент регулярно падал в Windows 10 и имеет тенденцию зависать на MacOS. Если вы ищете хорошее руководство по установке Stubby на Linux, то лучшая найденная мной документация — это пост Фрэнка Сантосо на Reddit. Он также написал shell скрипт для установки на Raspberry Pi.
Положительный момент в том, что Stubby допускает конфигурации с использованием нескольких служб на основе DNS по TLS. Файл конфигурации на YAML позволяет настроить несколько служб IPv4 и IPv6 и включает в себя настройки для SURFNet, Quad9 и других сервисов. Однако реализация YAML, используемая Stubby, чувствительна к пробелам, поэтому будьте осторожны при добавлении новой службы (например, Cloudflare). Сначала я использовал табы — и всё поломал.
Клиенты DNS по TLS при подключении к серверу DNS осуществляют аутентификацию с помощью простой инфраструктуры открытых ключей (Simple Public Key Infrastructure, SPKI). SPKI использует локальный криптографический хэш сертификата провайдера, обычно на алгоритме SHA256. В Stubby этот хэш хранится как часть описания сервера в файле конфигурации YAML, как показано ниже:
После установления TCP-соединения клиента с сервером через порт 853 сервер представляет свой сертификат, а клиент сверяет его с хэшем. Если всё в порядке, то клиент и сервер производят рукопожатие TLS, обмениваются ключами и запускают зашифрованный сеанс связи. С этого момента данные в зашифрованной сессии следуют тем же правилам, что и в DNS по TCP.
После успешного запуска Stubby я изменил сетевые настройки сети DNS, чтобы направлять запросы на 127.0.0.1 (localhost). Сниффер Wireshark хорошо показывает этот момент переключения, когда трафик DNS становится невидимым.
Переключаемся с обычного трафика DNS на шифрование TLS
Хотя DNS по TLS может работать как DNS по TCP, но шифрование TLS немного сказывается на производительности. Запросы dig к Cloudflare через Stubby у меня выполнялись в среднем около 50 миллисекунд (у вас результат может отличаться), в то время как простые DNS-запросы к Cloudflare получают ответ менее чем за 20 мс.
Здесь тоже имеется проблема с управлением сертификатами. Если провайдер удалит сертификат и начнёт использовать новый, то в настоящее время нет чистого способа обновления данных SPKI на клиентах, кроме вырезания старого и вставки нового сертификата в файл конфигурации. Прежде чем с этим разберутся, было бы полезно использовать какую-то схему управления ключами. И поскольку сервис работает на редком порту 853, то с высокой вероятностью DNS по TLS могут заблокировать на файрволе.
Google и Cloudflare, похоже, одинаково видят будущее зашифрованного DNS
Как Cloudflare, мы считаем, что туннели иллюстрируют операцию «Арго» лучше, чем Бен Аффлек
Дабы убедиться, что проблема именно в протоколе DoH, а не в программистах Cloudflare, я испытал два других инструмента. Во-первых, прокси-сервер от Google под названием Dingo. Его написал Павел Форемски, интернет-исследователь из Института теоретической и прикладной информатики Академии наук Польши. Dingo работает только с реализацией DoH от Google, но его можно настроить на ближайшую службу Google DNS. Это хорошо, потому что без такой оптимизации Dingo сожрал всю производительность DNS. Запросы dig в среднем выполнялись более 100 миллисекунд.
Это сократило время отклика примерно на 20%, то есть примерно до того показателя, как у Argo.
А оптимальную производительность DoH неожиданно показал DNSCrypt Proxy 2. После недавнего добавления DoH Cloudflare в курируемый список публичных DNS-сервисов DNSCrypt Proxy почти всегда по умолчанию подключается к Cloudflare из-за низкой задержки этого сервера. Чтобы убедиться, я даже вручную сконфигурировал его под резолвер Cloudflare для DoH, прежде чем запустить батарею dig-запросов.
Все запросы обрабатывались менее чем за 45 миллисекунд — это быстрее, чем собственный клиент Cloudflare, причём с большим отрывом. С сервисом DoH от Google производительность оказалась похуже: запросы обрабатывались в среднем около 80 миллисекунд. Это показатель без оптимизации на ближайший DNS-сервер от Google.
Я не Бэтмен, но моя модель угроз всё равно немного сложнее, чем у большинства людей
Я профессиональный параноик. Моя модель угроз отличается от вашей, и я предпочел бы сохранить в безопасности как можно больше своих действий в онлайне. Но учитывая количество нынешних угроз приватности и безопасности из-за манипуляций с трафиком DNS, у многих людей есть веские основания использовать какую-либо форму шифрования DNS. Я с удовольствием обнаружил, что некоторые реализации всех трёх протоколов не оказывают сильно негативного влияния на скорость передачи трафика.
Другая проблема в том, что, хотя прекрасные ребята из сообщества DNSCrypt проделали большую работу, но такая приватность по-прежнему слишком сложна для обычных людей. Хотя некоторые из этих DNS-клиентов для шифрования оказалось относительно легко настроить, но ни один из них нельзя назвать гарантированно простым для нормальных пользователей. Чтобы эти услуги стали действительно полезными, их следует плотнее интегрировать в железо и софт, который покупают люди — домашние маршрутизаторы, операционные системы для персональных компьютеров и мобильных устройств.
Интернет-провайдеры наверняка постараются активнее монетизировать обычный DNS-трафик, и никуда не исчезнут государственные агентства и преступники, которые стремятся использовать его во вред пользователю. Но маловероятно, что крупные разработчики ОС стремятся надёжно защитить DNS доступным для большинства людей способом, потому что они часто заинтересованы в монетизации, как и интернет-провайдеры. Кроме того, эти разработчики могут столкнуться с сопротивлением изменениям со стороны некоторых правительств, которые хотят сохранить возможности мониторинга DNS.
Так что в ближайшее время эти протоколы останутся инструментом для тех немногих людей, кто реально заботится о конфиденциальности своих данных и готов для этого немного потрудиться. Надеюсь, сообщество вокруг DNSCrypt продолжит свою активность и продвинет ситуацию вперёд.
Это подключение не защищено. Это веб-сайт может имитировать «название сайта» с целью кражи вашей личной и корпоративной информации. Вернитесь к предыдущей странице.
Скриншот, как обычно, прилагается.
Почему важно защитить DNS-трафик?
Когда приложение пытается получить доступ к веб-ресурсу, система создает DNS-запрос для преобразования доменного имени в IP-адрес. Как правило, этот запрос отправляется через DNS-сервер, настроенный в локальной сети. Один из рисков безопасности связан с тем, что запросы проходят по незашифрованному UDP-каналу. На практике это означает, что другие устройства могут не только видеть ваши запросы, но и взаимодействовать с ними и даже подменять ответы. Еще одна проблема заключается в доверии к DNS-резольверу в локальной сети. Например, если вы подключились к общедоступной Wi-Fi сети, то вашу Интернет-активность можно отследить или заблокировать.
Насколько шифрование DNS улучшает ситуацию? Использование защищенных протоколов позволяет обезопасить ваши DNS-запросы и DNS-ответы.
Если вы не доверяете сети, к которой подключены, то вы можете отправлять запросы на надежный DNS-сервер.
Safari
Нет данных. Разработчики Safari обычно опаздывают на все вечеринки по добавлению новых возможностей, а Apple недавно вкладывалась в конфиденциальность пользователей, поэтому есть все шансы, что у Safari появится поддержка DoH.
Firefox
Mozilla стала пионером этого протокола совместно с Cloudflare. Поддержка DoH уже есть в стабильных версиях Firefox. Её можно включить в настройках в разделе «Настройки сети».
Все критикуют реализацию DoH в Firefox потому, что браузер по умолчанию использует Cloudflare, перезаписывая настройки DNS.
Однако это значение можно поменять, прописав любой сервер с DoH. Из всех браузеров, поддержка протокола в Firefox реализована лучше всего, а настроить её легче всего – в основном потому, что разработчики имели с ней дело дольше остальных.
Сейчас браузер уже включает поддержку DoH по умолчанию для всех пользователей США. Поскольку британское правительство возражает против этого, для британских пользователей эта поддержка по умолчанию включена не будет.
В прошлом Mozilla не гарантировала включение DoH по умолчанию в других странах. Однако, поскольку поддержка протокола уже есть в стабильной версии браузера, пользователю остаётся лишь включить её, и всё будет работать.
Что делать?
- Проверить дату и время на iPhone. Ведь, вполне возможно, сертификат на посещаемом вами сайте «очень даже ничего», а Safari считает его просроченным только по одной причине — ваш iPhone живет в прошлом (будущем).
- Дождаться, пока владелец сайта обновит сертификат безопасности. С одной стороны — ждать можно долго. А с другой — тогда вы точно будете уверены в том, что ваше подключение к сайту максимально защищено.
- Проигнорировать предупреждение. Да, такое тоже возможно. Достаточно на странице с ошибкой нажать на кнопку «Подробнее», а затем выбрать «Если вы осознаёте риски, Вы можете посетить этот веб-сайт».
Причём, даже если вы нажмёте «проигнорировать», это не значит, что моментально произойдёт что-то плохое и получится:
Шеф, всё пропало! Гипс снимают, клиент уезжает (к/ф Бриллиантовая рука).
Нет, в большинстве случаев — никаких злоумышленников нет, а во всём виноват просроченный сертификат или неправильная дата и время на вашем устройстве.
Однако, как говорится, возможны варианты…
- Будьте бдительны.
- Старайтесь не посещать «сомнительные» ресурсы.
- А если уж посетили, то… опять-таки будьте бдительны.
И тогда, я очень надеюсь, всё будет «ОК»!
P.S. Ставьте «лайки», жмите на кнопки социальных сетей, задавайте вопросы, пишите в комментарии, будьте активней! Всем спасибо, всех обнял!:)
Причины ошибки
Safari на iPhone может ругаться на «Это подключение не защищено» только по одной причине:
Браузеру (Safari) не нравится сертификат безопасности, который установлен на том сайте, который вы пытаетесь посетить.
Чем конкретно не нравится? Тем, что он считает его просроченным и не актуальным в данный конкретный момент времени.
Chrome
Google Chrome стал вторым браузером после Firefox, добавившим поддержку DoH. Её можно включить, перейдя по следующему URL:
По-умолчанию DoH не включено для всех. Сейчас Google проводит ограниченный эксперимент с небольшим количеством пользователей, чтобы проверить, как DoH покажет себя при реальном использовании.
Поддержка DoH в Chrome отличается от Firefox, по-умолчанию перенаправляющего DoH-трафик на Cloudflare. Браузер после включения протокола будет отправлять DNS-запросы на всё те же сервера, что и ранее. Если у выбранного сервера окажется интерфейс с поддержкой DoH, тогда Chrome зашифрует DNS-трафик и отправит его на тот же DNS-сервер по протоколу DoH.
Благодаря этому Chrome не перехватывает DNS-настройки ОС – это очень ответственный подход, поскольку браузер может использоваться в условиях больших предприятий.
На текущий момент DoH в Chrome работает так:
- Пользователь вводит URL сайта в браузере.
- Chrome получает данные по DNS-серверу ОС.
- Он проверяет, есть ли этот сервер в белом списке одобренных серверов с поддержкой DoH.
- Если да, Chrome отправляет зашифрованный DNS-запрос на интерфейс этого сервера.
- Если нет, Chrome отправляет обычный DNS-запрос к этому серверу.
Однако есть два способа обойти это и заставить Chrome использовать DoH постоянно и вне зависимости от настроек DNS вашего провайдера.
Во-первых, можно воспользоваться обучающим материалом по принудительному включению поддержки DoH в Chrome. Во-вторых, пользователь может настроить DNS-сервер с поддержкой DoH в своей ОС. Его можно выбрать из списка, и это гарантированно будет работать в Chrome.
В следующем году Microsoft планирует выпустить новую версию браузера Edge на основе кода Chromium. Представитель Microsoft сообщил нам, что компания поддерживает DoH, но точные планы не раскрывает. Однако, версия Edge на основе Chromium уже поддерживает DoH. Её можно включить, перейдя по URL:
Это включит поддержку DoH, но она будет работать только, если ваш компьютер использует DNS с поддержкой DoH – чего в 99% случаев не происходит. Чтобы принудительно включить DoH в Edge, вы можете воспользоваться инструкцией из следующего поста в блоге одного из программистов Edge. Адрес сервера Cloudflare можно заменить на любой другой сервер DoH, который можно выбрать по ссылке. После соответствующей настройки, Edge способен работать с DoH.
Почему важно защитить DNS-трафик?
Когда приложение пытается получить доступ к веб-ресурсу, система создает DNS-запрос для преобразования доменного имени в IP-адрес. Как правило, этот запрос отправляется через DNS-сервер, настроенный в локальной сети. Один из рисков безопасности связан с тем, что запросы проходят по незашифрованному UDP-каналу. На практике это означает, что другие устройства могут не только видеть ваши запросы, но и взаимодействовать с ними и даже подменять ответы. Еще одна проблема заключается в доверии к DNS-резольверу в локальной сети. Например, если вы подключились к общедоступной Wi-Fi сети, то вашу Интернет-активность можно отследить или заблокировать.
Насколько шифрование DNS улучшает ситуацию? Использование защищенных протоколов позволяет обезопасить ваши DNS-запросы и DNS-ответы.
Если вы не доверяете сети, к которой подключены, то вы можете отправлять запросы на надежный DNS-сервер.
Opera
Opera уже встроила поддержку DoH. По умолчанию она выключена, но её можно включить в любой момент, и всё будет работать без дополнительных шагов.
Разработчики Opera используют модуль для работы с DoH сходный с тем, что используется в Firefox, и не оставляют всё на откуп провайдерам, как Chrome. Весь трафик браузера сейчас идёт через резолвер 1.1.1.1 от Cloudflare.
Мы не нашли способа поменять его на другой, но, по крайней мере, DoH в Opera работает. Однако работать с VPN он не будет – если вам нужен DoH, то его придётся отключить.
Чтобы включить DoH в Opera, зайдите сюда:
Как настроить AdGuard DNS в iOS 14
Как включить DoH в любом браузере
Вот, что нам известно на сегодня по поводу планов производителей браузеров, связанных с DoH, и о том, как пользователи могут включить DoH в любом браузере.
Настройка профиля
Просто откройте одну из следующих страниц в Safari на мобильном устройстве iOS:
AdGuard DNS
-
– блокировка рекламы, отслеживания, вредоносных сайтов и фишинга. – выполняет те же защитные функции, что и профиль AdGuard DNS и дополнительно блокирует сайты для взрослых, включает безопасный поиск в поисковиках и режим YouTube Kids. – без фильтрации контента и блокировок. Подходит, если вам нужен быстрый DNS-сервер без регистрации активности.
Comss.one DNS
-
– блокировка рекламы, отслеживания, вредоносных и фишинговых сайтов (основные серверы). – блокировка рекламы, отслеживания, вредоносных и фишинговых сайтов серверы для Сибири и Дальнего Востока.
После загрузки профиля перейдите в секцию Настройки. Там будет вкладка Профиль загружен.
Выберите эту опцию, просмотрите данные профиля и нажмите Установить.
Управлять профилями DNS можно в разделе Настройки > VPN и сеть > DNS. Вы можете переключаться между доступными профилями.
Чтобы проверить работу AdGuard DNS , перейдите на тестовую страницу AdGuard и убедитесь, что AdGuard DNS обнаружен.
Проверить работу Comss.one DNS можно с помощью сервиса DNS Leak Test (нажмите кнопку Extended test). Убедитесь, что все найденные DNS-серверы относятся к Comss.one DNS.
Если вы используете приложения AdGuard VPN или Adguard для iOS, то в приоритетном порядке будет использоваться настроенный в них DNS-сервер.
По сравнению с приложением AdGuard, у AdGuard DNS и Comss.one DNS есть несколько недостатков. Так вы не видите, какие именно запросы совершают установленные на устройстве приложения. Вы также не сможете использовать DNS-фильтрацию и вручную задавать, какие серверы нужно заблокировать, а какие разрешить.
Это делает DNS-трафик пользователя невидимым для сторонних наблюдателей за сетью, например, провайдеров. Однако если пользователи обожают DoH и считают его благом для конфиденциальности, провайдеры и производители средств кибербезопасности его ненавидят.
Британский провайдер назвал Mozilla «интернет-злодеем» за планы компании по внедрению DoH, а группу лоббистов от Comcast уличили в подготовке документа касательно DoH, который они планируют представить законотворцам Британии, надеясь предотвратить более широкое распространение протокола.
Однако, время уже может быть упущено. Редакция в течение недели связалась с производителями основных веб-браузеров, чтобы узнать об их будущих планах касательно DoH, и все они планируют внедрять протокол в том или ином виде.
Brave
«Мы очень хотим реализовать его», — сказал нам Том Лоуэнталь, менеджер продукта из Brave for Privacy & Security.
Однако у команды Brave пока нет точных сроков внедрения DoH. Они занимаются другими улучшениями, связанными с приватностью. К примеру, на этой неделе компания выпустила обновление, улучшающее распознавание скриптов, отслеживающих действия пользователей. На горизонте маячит версия Brave 1.0, и команде нужно сконцентрироваться на её выходе. Но DoH в Brave будет.
«Реализация DoH – это гораздо больше, чем простая техническая задача. Нам нужно решить, какие разумные и защитные установки мы можем включить по умолчанию для большинства людей, не задумывающихся о настройке DNS – но так, чтобы мы ничего не сломали у тех людей и организаций, что тщательно подошли к подстройке своих программ», — сказал Лоуэнталь.
Поскольку Brave основан на открытом проекте Chromium, в нём есть поддержка DoH. Однако команда пока не настроила эту поддержку. В коде она есть, но включается так, как это придумала команда авторов Google Chrome. Включить DoH в Brave можно, перейдя на следующий URL:
Читайте также: