dxdt.blog: занимательный интернет-журнал

В качестве ответа очередной порции проблем с доступностью NS-ов в RU-CENTER ввели, в дополнение к уже существующим, серверы, построенные с anycast. Теперь должно стать надёжнее.

В свежем журнале “Открытые системы” моя статья про технологию DANE (доступ по подписке). Напомню, что DANE – это весьма полезное улучшение для систем безопасности, действующих в Интернете: cуть DANE состоит в публикации дополнительной информации об использовании SSL-сертификатов при помощи DNS, защищённой DNSSEC.

(Я часто писал про DANE на dxdt.ru.)

DNSSEC удостоверяет информацию, размещаемую в DNS. Вообще, современное понимание DNS сильно шире простого преобразования “символьное имя <-> числовой адрес”. Эту систему рассматривают как распределённую базу данных, хранящую некие пары значений и снабжённую не менее распределённым механизмом для поиска. То, что при помощи DNS можно сопоставлять символьные имена хостов и IP-адреса – это лишь одно из применений полезного сервиса.

Например, существует такая ресурсная запись (то есть, пара значений из базы данных DNS) – SSHFP, SSH FingerPrint. Эта запись позволяет разместить в DNS отпечаток серверного криптографического ключа, используемого для доступа при помощи SSH. Зачем? Для того, чтобы SSH-клиент мог сверить данные, полученные при установлении соединения от сервера, с данными, размещёнными в DNS, и лишний раз убедиться, что всё в порядке, канал никто не перехватывает – или наоборот: перехватывает.

Для того, чтобы схема имела смысл, доменная зона должна быть безопасной, подписанной DNSSEC. Понятно, что подписанная зона удостоверяет IP-адрес, с которым будет устанавливаться соединение по SSH. Но DNS никак не гарантирует, что это соединение не перехвачено на уровне IP, и атакующий не подменяет сервер.

Включить проверку можно при помощи настройки SSH-клиента. Например:

$ ssh -o VerifyHostKeyDNS=yes test@example.com

(Понятно, что опцию VerifyHostKeyDNS можно просто указать в конфигах.)

Отпечаток, размещаемый в DNS, генерируется (в Linux-ах) при помощи следующей команды:

$ ssh-keygen -r dxdt.ru

Например, я держу такую запись в зоне dxdt.ru, которая, естественно, подписана DNSSEC. Выглядит запись так:

dxdt.ru. IN SSHFP 1 1 0A1D19C05D239CCE90EE616DEB2EF80B35F3759B

– посмотреть может каждый, опросив серверы, поддерживающие зону.

На мой взгляд, полезное применение DNSSEC.

На stat.nic.ru – очередное обновление: большая статья с результатами исследования веб-технологий, используемых в Рунете, и их сравнением с международным сегментом Сети (тему в RU-CENTER ведёт Артемий Ломов). Данных много, поясняющего текста тоже немало. Рекомендую всем, кому интересно, как сейчас устроен рунетовский веб. Исследование, вообще говоря, уникальное.

ICANN принимает комментарии общественности по вопросу ротации корневого KSK, используемого в глобальной DNSSEC. Корневую зону DNS администрирует организация IANA (при участии VeriSign). Напомню, что для генерации подписей корневой зоне используют ключ ZSK (Zone Signing Key), который, в свою очередь, удостоверен подписью, полученной при помощи корневого KSK (root Key Signing Key). Этот последний KSK является неким самым главным ключом от DNS, встроенным в валидирующие резолверы, позволяющим строить “цепочку доверия”.

Криптографические ключи принято периодически менять. Занятно, что для корневого KSK за эти годы не было предложено стандартной процедуры ротации. Основная проблема состоит в том, что клиентские резолверы, которых уже существует большое разнообразие, могут не получить новый ключ. Многие из них настроены вручную и, несмотря на существование RFC5011, рискуют остаться со старым ключом, который станет непригоден для проверки подписей. Таким образом, валидация сломается, адреса перестанут работать, а те, кто использует валидирующие резолверы – опять разозлятся и отключат DNSSEC. Ну, возможно, отключат.

Комментарии по проблеме принимают до 31 мая. Эту дату могут и сдвинуть. Когда проведут ротацию ключей и каким методом – пока вообще не ясно. Скорее всего, будет отдельный проект и несколько рабочих групп. Это в традиции ICANN.

Занятный момент есть в официальном FAQ по Google Public DNS – они пишут, что если адрес, который не проходит валидацию DNSSEC, является популярным и хорошо известным, то для него может быть сделано исключение: валидацию отключат.

Вообще говоря, учитывая ошибки в управлении безопасными зонами (с DNSSEC), решение выглядит разумно: невалидным может оказаться и какой-нибудь домен первого уровня, без всяких атак злоумышленников, такое уже случалось несколько раз (тут как бы в корне подписи не “обрушили”, что уж говорить о доменах уровнем ниже).

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

Цитата из FAQ:

How does Google Public DNS handle lookups which fail DNSSEC validation?

If a client requests a validated lookup for a signed domain, but Google Public DNS cannot validate the lookup (due to misconfiguration, missing or incorrect RRSIG records or DNSKEY records, etc.), it will return an error response (SERVFAIL). However, if the impact is significant (e.g. a very popular domain is failing validation), we may temporarily blacklist the zone from validation until the problem is fixed.

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

Методика проверки простая: заводим специальную доменную зону, вносим в неё отдельную запись, предназначенную для тестирования, после чего запрашиваем значение этой записи через сервис “Яндекса” и смотрим в логи авторитативного сервера имён (NS). Так как это тест, а зона третьего уровня, то авторитативный сервер – один. DNS так устроена, что хотя бы один раз какой-то сервер “Яндекса” должен прийти к нам с запросом.

Беда в том, что “Яндекс” пришёл далеко не один раз, не дождавшись истечения TTL (“время жизни” ответа, управляющее продолжительностью нахождения данных в кэше). Можно предположить, как всё это устроено на стороне “Яндекса”: используется группа серверов-резолверов (часть из них имеет адреса из диапазона 213.180.200.240/29), с раздельными кэшами, балансировка входящих запросов не учитывает состояние кэшей, взятое относительно источника запроса. То есть, пока каждый резолвер не загрузит данные, требуемые для ответа на запрос, вероятность попасть в кэш мала. Дело в том, что последовательные запросы отрабатывают разные резолверы: хорошо видно, как они повторно приходят на NS до истечения TTL.

Результат: кэширование реализовано вне традиций DNS. Одинаковые повторные запросы даже для одного и того же клиента, до истечения TTL, постоянно уходят на авторитативные серверы, что прямо противоречит смыслу существования подобного “кэширующего” резолвера (DNS-сервера), а в случае распространения “Яндекс.DNS”, создаёт ненужную дополнительную нагрузку, то есть заметно ухудшает ситуацию: вместо одного запроса провайдерского резолвера получаем несколько (пять-десять) запросов от “Яндекса”.

(Да, Google Public DNS кэширует правильно, повторно раньше времени не приходит.)

Думаю, в “Яндексе” есть объяснение, почему так сделано. Но сделано некрасиво. Даже для бета-версии.

“Яндекс” запустил открытый сервис DNS (открытые резолверы). Сервис похож на Google Public DNS. Однако у яндексового варианта есть дополнение – фильтрация адресов:

Яндекс.DNS – это бесплатный DNS-сервис, блокирующий опасные сайты и сайты для взрослых.

(http://dns.yandex.ru/)

Мода на фильтрацию добралась и до “Яндекса”. Реализация, впрочем, весьма странная. Тем более, для “Яндекса”. Особенно на фоне того, что недавно они анонсировали собственный браузер. Поясню: подменять ответы DNS – это весьма порочная практика, угрожающая стабильности системы доменных имён. Сервис “Яндекса” именно подменяет ответы. И делает это криво.

При обработке запроса об адресе “заблокированного” ресурса приходит ответ, содержащий IP-адрес некоего принадлежащего “Яндексу” сервера перенаправлений, который отвечает по HTTP (это уже прямая подмена соединения!) редиректом на специальную страницу внутри yandex.ru. Эта страница устроена так, что охотно показывает сообщение о блокировании любого адреса, который передан в параметре URL-а. Например: http://yandex.ru/adult?url=yandex.ru – пишет, что “заблокирован” yandex.ru. Это, мягко говоря, технологически некрасиво. (Да, многие операторы связи сейчас делают подобное. Это известно.)

Почему плохо портить ответы DNS? Прежде всего потому, что пользователь остаётся с заведомо сломанным сервисом резолвинга, в который добавлена ещё пара уязвимых точек. Одна ошибка администраторов может перенаправить массу пользователей добропорядочного сайта на некую страницу-заглушку. И это в лучшем случае. В худшем, если сервис поломают, – получаем классический фишерский инструмент с подменой DNS. Обратите внимание, что пользователи подобных сервисов заведомо остаются без DNSSEC. Это при том, что Google Public DNS поддержку DNSSEC наоборот – внедряет (в комментариях уточнили: уже внедрил). Да, понятно, что взломать могут и резолвер интернет-провайдера. Проблема в том, что потенциальная аудитория сервиса “Яндекса” куда как более разнообразна, дефект, при этом, заложен в этот сервис архитектурно, чего нельзя сказать о стандартных резолверах.

Естественно, блокировать нехороший контент нужно. Но для этого не требуется ломать DNS. Нужно использовать белые и чёрные списки, встроенные в браузер. И подходящий браузер у “Яндекса” есть.

Поделюсь, пожалуй, кратким описанием Интернета.

Интернет – это группа постапокалиптических технологий, не дождавшихся своего часа.

Можно добавить: пока не дождавшихся. Хотя, нельзя со всей уверенностью сказать, что современный Интернет может пережить всякий конец Цивилизации.

Нередко спрашивают, где посмотреть на примеры SSL-сертификатов, связанных с тем или иным инцидентом, отражающим очередной провал в работе удостоверяющих центров. Откроем браузер Firefox, я взял версию 19.0.2, найдём там в настройках раздел Advanced, воспользуемся вкладкой Encryption и кнопкой View Certificates, выбрав в открывшемся окне вкладку Servers (я сделал скриншот):

– пожалуйста, вот некоторые сертификаты, выпущенные с использованием брешей в инфраструктуре УЦ. В базе Mozilla они отмечены как недоверенные. В дистрибутиве браузера они находятся по практически историческим причинам, так как использовались (или могли использоваться) в Сети. В принципе, воспользовавшись ручными настройками и сейчас можно сделать некоторые из представленных сертификатов доверенными (кроме тех, у которых истёк срок действия). Естественно, если настройки не изменять, то при обнаружении любого из этих сертификатов в ответе TLS-сервера, браузер выдаст предупреждение системы безопасности.

Ещё немного по теме прослушивания Skype. Из сообщений представителей самого Skype и отчётов аудиторов давно известно, что это ПО использует стандартные криптографические примитивы (AES, RSA и так далее), но местами делает это, на уровне протоколов, проприетарным образом. Да, понятно, что, например, AES, в качестве основы шифрования потока данных, – это хороший тон. Да, Skype использует P2P-сеть для транспорта трафика, а ключи, как заявлено, генерируются на клиенте. Всё это хорошо. В теории. Вопрос – можно ли организовать прослушивание?

Ответ есть. Сразу оговорюсь, он тоже чисто теоретический. Протоколы обмена ключами между сторонами, образующими то самое P2P-соединение, нередко базируются на присутствии третьей стороны, которой доверяют оба участника. Третья сторона удостоверяет данные участников обмена информацией, в том числе, сессионные ключи от AES. Это стандартное хорошее решение (но не единственно возможное, заметьте). Насколько я помню, Skype использует собственный удостоверяющий сервер, открытые ключи которого известны клиентскому ПО и позволяют проверять подлинность рекивзитов других пользователей при установлении соединения.

Итак, этот сервер удостоверяет реквизиты (логин, пароль, ключ) участников звонка. Так вот, такой сервер может подписать (удостоверить) дополнительные реквизиты некоторого “человека посередине”, который будет успешно выдавать себя за другую сторону, осуществляющую звонок, для каждого из участников переговоров. Опять же, в такой атаке нет ничего нового. Она стандратна. Более того, если секретные ключи удостоверяющего сервера Skype кому-то передать, то этот кто-то сможет самостоятельно выпускать нужные подписи влёт.

Впрочем, остаётся решить задачу перехвата трафика, который, в теории, может ходить между клиентами самыми разными путями. Это отдельная тема. Но обратите внимание на то, что для подавляющего большинства пользователей Skype существует одна “последняя миля” (то есть, канал от интернет-провайдера до клиента), и даже из больших сетей со множеством пользователей трафик уходит всего через несколько хорошо известных узлов.

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