Лайкнуть
Лайкнуть
Твитнуть
Расскажу о программе, которой пользуюсь уже много лет. Она немного улучшает сетевую безопасность, защищая от подмены сайтов при работе через небезопасные Wi-Fi сети.
Углубляться в технические подробности я не буду. Сжато расскажу суть проблемы, которую начали решать только в последние лет 5, но с помощью DNSCrypt можно защититься уже сегодня.
Для общения устройств используется способ передачи данных TCP/IP. Это не протокол или набор программ, а концепция (модель) того, как это общение должно происходить.
У TCP/IP много недостатков, но, так как модель «пластичная», её латают и дорабатывают на протяжении более 40 лет своего существования. Например, чтобы никто не видел, что вы вводите на сайтах и получаете в ответ, многие сайты массово перешли на шифрованный протокол
К сожалению, уязвимостей в TCP/IP пока предостаточно. Одно из больных мест - система доменных имён (D omain N ame S ystem, DNS).
Когда вы открываете в адресной строке сайт, компьютеру нужно узнать, на какой сервер послать запрос. Для этого он обращается к серверам DNS, хранящих записи о том, на какой цифровой IP-адрес сервера обратиться, чтобы получить нужную страничку.
Проблема в том, что компьютеры безоговорочно доверяют серверам DNS. Если вы подключитесь к публичной Wi-Fi сети в кафе, владелец которой поднял собственный сервер с ложными адресами, есть шанс, что вместо Вконтакте вы откроете обманку, собирающую пароли.
Способов защитить запросы к серверам имён несколько, но операционные системы их не используют. Нужно дорабатывать ОС самостоятельно с помощью отдельных программ.
Simple DNSCrypt позволяет легко и просто изменить настройки сетевой карты так, чтобы все запросы шли к DNS серверам с поддержкой DNSSEC. Эта технология позволяет избежать подмены IP-адресов. Как бонус, будут использоваться только уважающие приватность серверы имён, т.е. не сохраняющие обращения пользователей.
Программа ставится просто. Главное правильно выбрать 32- или 64-битную версию, смотря какой разрядности у вас Windows. Разрядность можно посмотреть в Панели управления - Система (в Windows 10 - Параметры - Система - О программе).
После установки и запуска с ярлыка на Рабочем столе настройки менять не нужно. Просто нажмите кнопку «Применить».
Вы увидите, что переключатель пункта «Служба DNSCrypt» установится в зелёное положение «Вкл». Значит, в Windows запустилась новая служба, суть которой - выступать прокси-сервером всех DNS-запросов, перенаправляя их на безопасные сервера (их список есть на вкладке «Резольверы», там ничего трогать не надо).
После нужно лишь щёлкнуть мышью по всем сетевым картам, видимым в нижней части окна, чтобы на них появилась галочка справа вверху.
На этом всё! Защита запросов заработает сразу. Программа будет работать сама по себе.
Если вы продвинутый пользователь и хотите проверить, работает ли DNSCrypt на вашем компьютере, откройте свойства протокола TCP/IPv4 сетевого соединения. DNS-сервер должен быть локальный - 127.0.0.1.
Если при использовании сервера имён 127.0.0.1 сайты открываются - утилита dnscrypt-proxy работает, никто ваши запросы не пишет и провайдер запросы не отслеживает.
Удаляется программа, как и все остальные - через Панель управления.
Не путайте шифрование DNS с шифрованием всего трафика между вами и сайтами.
DNSCrypt поможет
Утилита не поможет
Если вы обеспокоены вопросами конфиденциальности, DNSCrypt выступит лишь вспомогательным инструментом. Для анонимного сёрфинга в интернете используются технологии VPN и/или Tor, тогда шифрование DNS станет дополнительной защитой на случай, если какая-то программа на вашем компьютере запросит IP-адрес домена в обход VPN.
Если использовать DNSCypt без VPN, провайдер по-прежнему будет видеть, что вы обращаетесь к серверу с таким-то IP, и если на сервере с одним IP-адресом хостится несколько сайтов, то определить, на какой именно вы зашли, у него получится с помощью анализа запросов (запись Server Name Indicator передаётся открытым текстом даже при использовании HTTPS).
Шифрование DNS должно работать по умолчанию в любой операционной системе. Но этой функции там нет! Ни в Windows, ни в Linux, ни в Android, нигде нет поддержки DNSCrypt или аналогичной технологии «из коробки».
Корпорация по управлению доменными именами и IP-адресами (ICANN) готовится к замене криптографических ключей защиты DNS-серверов 11 октября. Если что-то пойдет не так, у миллионов пользователей возникнут проблемы с интернетом.
Система адресации Всемирной паутины устроена таким образом, чтобы нам не приходилось запоминать цифровые IP сайтов - достаточно знать URL на естественном языке (например, сайт вместо 80.93.184.195). DNS-сервер (от англ. Domain Name System) выполнит задачу переводчика за нас и определит, какой веб-ресурс мы ищем, набирая тот или иной адрес или кликая по строке выдачи поисковика.
С тех пор как Сеть стала площадкой для бизнеса, с каждым годом росло число жертв кибермошенников, которые перехватывали запрос пользователя к DNS-серверу и вместо нужного сайта перенаправляли его на подставной, порой визуально неотличимый от оригинала. Поэтому в 2010 году ICANN ввела систему ключей KSK (от англ. Key Signing Key) - расширений безопасности системы доменных имен (DNS Security, или DNSSEC), срок замены которых давно истек.
Зоны корневых DNS-серверов
Источник: Википедия.
KSK используются для дополнительной защиты запросов пользователей к системе DNS. Они устанавливаются в конфигуратор (якорь доверия) на серверы корневых (валидирующие резолверы) и локальных (рекурсивные резолверы) доменных зон и обеспечивают гарантию соответствия указанного в запросе URL подлинному IP-адресу. KSK по регламенту подлежат замене каждые пять лет. Но поскольку срок полномочий правительства США по управлению доменными именами истек, а многие крупные операторы оказались не готовы, решили не спешить.
Всерьез про обновление ключей заговорили в июле 2016 года, а на днях корпорация объявила готовность номер один - 11 октября запланирована деактивация действующей версии KSK и переход к новой. Поскольку у операторов было достаточно времени на обновление конфигураторов резолверов, смена ключей должна пройти автоматически и незаметно для остального мира. Более того, двое из каждых трех пользователей интернета вообще не имеют отношения к DNSSEC.
Однако, по оценке самой ICANN, существует вероятность, что некоторые резолверы по каким-то причинам оставят в якоре доверия старые ключи - в таком случае DNS-сервер просто не сможет понять, какой сайт у него запрашивают. При этом в силу особенностей валидации ключей корневой доменной зоны так называемыми авторитетными DNS-серверами (отвечающими за домены первого порядка, например, зону.ru) последствия могут проявиться спустя двое суток.
Криптографические офицеры ICANN предупреждают, что для 750 млн рядовых пользователей это может обернуться непредсказуемыми ошибками доступа к странице в браузере (типа «server failure» и SERVFAIL) или загрузкой сайта без картинок, сбоями при обмене почтой, битыми сообщениями и общим замедлением быстродействия Сети. Более серьезные последствия грозят автоматизированным системам и сервисам, подключенным к DNSSEC - сломается не просто синхронизация времени, а весь электронный документооборот.
Помимо этого, ICANN ожидает существенный рост вычислительной нагрузки на всю иерархию DNS из-за увеличения числа запросов на обновление KSK от операторов со старыми ключами. Результаты мониторинга ситуации обещают публиковать на сайте корпорации.
Нередко спрашивают, что такое DNSCrypt и зачем это нужно. Некоторое время назад я уже писал про , тогда речь шла о поддержке в бета-версии браузера. В этот раз посмотрим на технологию в подробностях, а “Яндекс.Браузер” послужит примером и источником лабораторных данных. Разбор пакетов я провожу в Wireshark, для которого написал небольшой парсер DNSCrypt (в терминологии Wireshark – это dissector, на языке Lua; штатного парсера DNSCrypt в Wireshark-е мне выявить не удалось).
DNSCrypt – это прокси-сервис, создающий защищённый канал между клиентским резолвером DNS и рекурсивным DNS-резолвером, исполняемым на сервере. У DNSCrypt, соответственно, две части: клиентская и серверная. Через трафик DNS, который штатно передаётся в открытом виде, могут утекать сведения о посещаемых сайтах. Кроме того, запросы DNS – распространённый вектор атак для подмены адресов. Замена адреса системного резолвера DNS на адрес подставного сервера является общим местом троянских программ уже много лет. То же самое относится к атакам на домашние роутеры. DNSCrypt позволяет зашифровать (а также – ограниченно защитить от подмены) и запросы, и ответы DNS. Предусмотрена возможность аутентификации сервера и клиента, но эта возможность не всегда используется. Вообще, тема сокрытия DNS-трафика (DNS Privacy) сейчас набрала заметную популярность. Кроме DNSCrypt, существует, например, протокол “DNS через TLS” (DNS over TLS – свежий RFC 7858 , который, несмотря на некоторую “перевёрнутость”, выглядит не хуже DNSCrypt). Есть и другие разработки.
DNSCrypt. Протокол может использовать в качестве транспорта как TCP, так и UDP. На практике, предпочтение отдаётся UDP, если он доступен, но спецификация строго требует поддержки именно TCP (не UPD, поддержка которого опциональна). TCP, естественно, привлекает сессионной природой. Но UDP – гораздо быстрее, особенно для нагруженных сервисов. Из-за проблем с DDoS-атаками и некоторых других вопросов обеспечения безопасности, сейчас наметилось модное движение в сторону перевода максимального числа сервисов на TCP, это особенно касается DNS. Тем не менее, ниже я рассматриваю работу DNSCrypt только по UDP, так как это традиционный для DNS вариант. Рекомендованный номер (серверного) порта DNSCrypt – 443 (он обычно открыт в корпоративных сетях; практика использования 443/udp, например, является стандартной для целого ряда VPN и других сервисов; 443/tcp – это TLS/HTTPS, фундамент веб-сервисов). Впрочем, “Яндекс” в своей реализации DNSCrypt использует непривилегированный номер: 15353, вероятно, это связано с какими-то идеями по преодолению разнообразных сетевых барьеров.
Чуть подробнее о барьерах: никаких проблем с блокированием трафика DNSCrypt, при наличии такого желания у провайдера канала, не возникнет. Как будет ясно из описания ниже, этот протокол никак не пытается скрыть сам факт своего использования. В трафик данного протокола включаются стандартные маркеры, которые позволят обнаружить и зафильтровать пакеты даже на самом примитивном маршрутизаторе, с помощью нехитрого правила “в две строчки”. При этом, например, доступ для других TCP-сессий, работающих на 443 порту, сохранится.
В DNSCrypt установление сессии между клиентом и сервером начинается с обычного DNS-запроса, отправленного на адрес и соответствующий номер порта узла, который будет предоставлять функции резрешения (резолвинга) имён. Это запрос TXT-записи для имени специального вида (то есть, запрос уже можно легко зафильтровать). Например, в случае с сервисом “Яндекса”: 2.dnscrypt-cert.browser.yandex.net. Это специальное имя может быть не делегировано. Значение 2 – соответствует версии DNSCrypt. Актуальная версия – вторая . В ответ сервер должен прислать один или несколько сертификатов DNSCrypt (подчеркну: они не имеют никакого отношения к SSL-сертификатам).
На скриншоте – пакет с сертификатом от сервера DNSCrypt “Яндекса”.
Сертификат представляет собой набор из нескольких полей: версия сертификата, значение подписи, открытый ключ сервера, magic-байты для клиента (они послужат идентификатором клиентских запросов – сервер сможет понять, какой ключ использовать при ответе), серийный номер и срок действия.
Спецификация предполагает, что в составе сертификата сервер передаёт кратковременный открытый ключ. (Впрочем, в случае с сервером “Яндекса”, данный ключ не меняется, как минимум, с конца марта, когда была запущена бета-версия браузера с поддержкой DNSCrypt.) Подпись на сертификате должна генерироваться от другой пары ключей. Открытый ключ этой пары известен клиенту – он необходим для проверки подписи. Очевидно, подписывать сертификат тем же ключом, который используется в рамках сессии – бессмысленно. Я не проверял, проводит ли валидацию серверного сертификата “Яндекс.Браузер”. Дело в том, что в модели угроз, на которую ориентировано использование DNSCrypt в “Яндекс.Браузере”, валидация сертификата особого смысла не имеет, как и сравнение значения ключа с сохранённой копией (я вернусь к этому моменту ниже).
В качестве криптографических примитивов DNSCrypt использует конструкции из шифра Salsa20 (XSalsa20), хеш-функции Poly1305 (для реализации аутентифицированного шифрования) и алгоритм X25119-hsalsa20 для выработки общего сеансового ключа (алгоритм использует эллиптическую кривую Curve25119 и хеш-функцию hsalsa20). Эти конструкции разработаны Даниэлем Бернштейном (Daniel J. Bernstein) и давно получили признание как весьма добротные. Алгоритм получения общего секрета (сеансового ключа) математически родственен алгоритму Диффи-Хеллмана. Отмечу, что общий секрет в данном случае можно восстановить постфактум, если станет известен соответствующий секретный ключ из пары серверных (или клиентских) ключей, это позволит расшифровать ранее записанный трафик, именно поэтому спецификация рекомендует использовать кратковременные ключи.
Шифр XSalsa20 в режиме аутентифицированного шифрования требует nonce длиной 192 бита (24 байта). Повторное использование одного и того же сочетания ключа и nonce не допускается. Это связано с архитектурой шифра XSalsa20 – повторное использование nonce приведёт к утечке: прослушивающей стороне станет известно значение XOR от пары соответствующих открытых текстов. Поэтому nonce должно быть каждый раз новым, но не обязательно случайным. Параметр nonce в DNSCrypt присутствует в двух воплощениях: клиентской и серверной.
Посмотрим на зашифрованный клиентский запрос , отправляемый “Яндекс.Браузером”.
Первое поле запроса – это клиентское значение magic (Client query magic bytes): здесь используется часть открытого ключа сервера, полученная ранее. При необходимости, данные “магические байты” могут служить сигнатурой, позволяющей выбирать в трафике запросы, отправляемые к DNSCrypt;
Следующее поле – кратковременный клиентский открытый ключ (Client public key);
Клиентское значение nonce – 96 бит (12 байтов), половина от требуемого значения nonce для шифра XSalsa20 (согласно спецификации DNSCrypt, дополняется байтами со значением 0). Можно использовать тот или иной счётчик, “Яндекс.Браузер” так и поступает: cудя по всему, здесь передаётся 64-битное значение миллисекундного таймстемпа (время формирования запроса), к которому дописываются четыре байта псевдослучайных значений. На случай, если это действительно точное время, передаваемое в открытом виде, отмечу, что параметры дрейфа системных часов служат неплохим признаком, идентифицирующим конкретное аппаратное устройство, – то есть, могут быть использованы для деанонимизации;
Последнее поле – это сам зашифрованный запрос. Для шифрования используется общий секретный ключ, который вычисляется сторонами на основании переданных открытых ключей. В случае с клиентом – открытый ключ передаётся в пакете DNS-запроса (см. выше). “Яндекс.Браузер” следует стандартной практике и генерирует новую пару ключей (открытый/секретный) для X25119-hsalsa20 при каждом старте барузера. Для выравнивания данных на границу 64-байтового блока, как предписывает спецификация, используется стандартное дополнение (ISO/IEC 7816-4: 0x80 и нулевые байты в требуемом количестве).
Блок зашифрованных данных – это, скорее всего, результат использования функции crypto_box из библиотеки libsodium (либо NaCl, на которую ссылается спецификация DNSCrypt; libsodium – это форк NaCl). Я предположил, что 16-байтовый код аутентификации (MAC), который используется для проверки целостности сообщения перед расшифрованием, находится, вероятно, в начале блока. Впрочем, так как расшифровать данные я не пытался, то и определение расположения кода не столь важно. Для расшифрования можно использовать секретный ключ, который содержится в памяти во время работы браузера, но чтобы его извлечь – нужно некоторое время повозиться с отладчиком и дизассемблером.
Зашифрованный ответ, полученный от сервера:
(Нетрудно заметить, что ответ, представленный на скриншоте, поступил почти через пять секунд после запроса, почему так получилось – видимо, тема для отдельной записки.)
Пакет открывается magic, в данном случае, это байты, содержащие маркер ответа DNSCrypt (опять же, хорошая сигнатура для обнаружения трафика). Эти байты определены протоколом и должны присутствовать в начале всякого ответа сервера на запрос DNS-резолвинга;
Следующее поле – nonce (Response nonce). Поле содержит значение nonce, использованное сервером при шифровании данного ответа. Поле строится из двух равных частей, по 12 байтов: nonce из соответствующего клиентского запроса и серверное дополнение;
Заключительная часть пакета – зашифрованные данные ответа, формат аналогичен запросу.
Теперь вернёмся к модели угроз, на примере “Яндекс.Браузера”. Если в настройках браузера включено использование DNSCrypt, например, через серверы “Яндекса”, но доступ к соответствующему серверу заблокирован, то браузер (как и бета-версия) прозрачно, без предупреждений, переходит к использованию системного резолвера. Почему это лишает смысла необходимость валидации сертификатов серверов DNSCrypt? Потому что активная атакующая сторона, которая может подменять пакеты на уровне IP, для отключения DNSCrypt в браузере может просто заблокировать доступ к серверу, вместо того, чтобы тратить ресурсы на поделку ответов. Из этого можно сделать вывод, что модель угроз “Яндекса” не включает активную подмену пакетов на пути от сервера DNSCrypt к клиенту.
В качестве завершения, пара слов о том, как DNSCrypt относится к DNSSEC. DNSSEC – не скрывает данные DNS-трафика, но защищает их от подмены, вне зависимости от канала обмена информацией. В случае с DNSSEC – не имеет значения, по какому каналу получены данные из DNS, главное, чтобы ключи были на месте. DNSCrypt – скрывает трафик и ограниченно защищает его от подмены на пути от рекурсивного резолвера (сервиса резолвинга) до клиента. Если данные были подменены на пути к резолверу (или на самом сервере резолвера), а он не поддерживает DNSSEC, то клиент получит искажённую информацию, хоть и по защищённому DNSCrypt каналу. Серверы, предоставляющие DNSCrypt, могут поддерживать и DNSSEC.
