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

Технология под названием DANE (DNS-Based Authentication of Named Entities) позволяет размещать в DNS информацию, идентифицирующую заданные элементы криптосистем, используемых различными сервисами в Интернете. DANE распространяет удостоверяющие свойства DNSSEC на другие протоколы, тем самым сильно расширяя возможности и область применения DNSSEC.

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

Пока что DANE находится в разработке, которая, надо заметить, идёт неплохо: примерно за год активной деятельности рабочей группы соответствующий RFC уже добрался до завершающей стадии подготовки. Тем не менее, говорить о какой-то поддержке приложениями пока что рано, протокол всё ещё экспериментальный, его ключевые особенности могут измениться. Кроме того, требуется продвижение идеи в пользовательские браузеры.

В качестве тестовой площадки я сделал https://dane.nox.su/ – понятно, что заходить туда имеет смысл только по https. Более того, приготовьтесь увидеть предупреждение системы безопасности браузера. Подробности – ниже.

Как это работает? Основной момент в том, что информация об открытом ключе SSL-сертификата вносится в подписанную зону DNS. В случае с dane.nox.su – с этим проблем нет, так как зона nox.su поддерживает DNSSEC. Веб-сервер dane.nox.su использует самоподписанный SSL-сертификат. Это сделано специально, так как одной из интересных особенностей DANE является то, что этот новый инструмент, благодаря DNSSEC, позволяет превратить самоподписанный (бесплатный, заметьте) сертификат во вполне сносный механизм аутентификации веб-сайта. Хотя, на практике лучше использовать не самоподписанный, а полноценный сертификат – с ним DANE, понятно, также совместим.

Процедура настройки DANE для TLS довольно проста. Я опущу описание процесса генерации SSL-сертификата, предположим, что он уже есть и установлен. Требуется добавить в зону DNS запись особого вида, содержащую отпечаток (хеш) открытого ключа сертификата. Используем SHA-256 (один из вариантов, указанных в RFC). Прежде всего, отпечаток нужно получить:

$ openssl x509 -noout -fingerprint -sha256 -in yourcert.crt

– здесь yourcert.crt – файл с вашим сертификатом.

Вообще, для использования в DNS, значение SHA-256 потребуется в записи без двоеточий, так что лучше сразу сказать как-то так:

$ openssl x509 -noout -fingerprint -sha256 -in nox.su.self.crt | perl -ne ‘s/://g; print $_’

Результат примерно такой (для сертификата dane.nox.su):

SHA256 Fingerprint =
12B1BC2AF0D87C6E0E259CE364CE6921
B74F0C748328C4A33A11F19467700EB2

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

Запись DNS выглядит, соответственно, так (для dane.nox.su):

_443._tcp.dane.nox.su. IN TYPE65468 \# 35
( 03000112B1BC2AF0D87C6E0E259CE364CE6921
B74F0C748328C4A33A11F19467700EB2 )

Думаю, нетрудно догадаться, что имя построено из номера порта, типа протокола и хоста: TCP и 443 – это стандартный транспорт HTTPS. Тип TYPE65468 – это временный тип записи, выделенный для тестирования DANE. Собcтвенно, сейчас IANA уже выделила “нормальный” тип – TLSA (52). Но с TLSA пока что удобства ещё меньше.

Значение: тут к отпечатку, в качестве префикса, добавлено три байта (октета), со значениями 03,01,01. Это, в порядке следования:

* метод использования сертификата – 3 – обозначает, что сертификат не должен проверяться по цепочке доверия (PKIX) браузера, а только сверятся с отпечатком в DNS; подходит для самоподписанного сертификата; другие варианты предусматривают проверку цепочки внутри иерархии подписей;

* проверяемая часть сертификата – 1 – проверятся отпечаток открытого ключа; 0 – проверяется отпечаток всего сертификата;

* тип хеш-функции – 1 – SHA-256; тут всё понятно.

То есть, значение записи строится так: {метод}{часть}{тип-хеша}{значение-хеша} – просто и прозрачно. Извлечь тестовую запись, вместе с подписью, из DNS можно попробовать такой командой:

$ dig +dnssec -t TYPE65468 _443._tcp.dane.nox.su

После того, как запись успешно размещена в зоне и зона подписана – всё готово для использования DANE.

Тут и кроется основная практическая трудность (или, скажем так, засада): поддержки DANE пока нет. Из того, что мне удалось обнаружить: плагин для Firefox Extended DNSSEC Validator, альфа-версия. В принципе, Chrome должен поддерживать DANE, но, на правах первопроходца, он делает это в манере, отличающейся от описанной в текущем RFC (который, напомню, черновик). Для того, чтобы заработал Chrome, требуется другая запись в DNS и специальное поле в сертификате. Поэтому, в случае с dane.nox.su, Chrome выдаёт предупреждение о “плохом” сертификате. Надеюсь, что по мере развития технологии, всё нормализуется и будет один стандарт.

Вот, кстати, к вопросу о том, что на свободе по пользовательским компьютерами может разгуливать куча вредоносного ПО, которое современные меганавороченные антивирусы не распознают (просто, хвалёные эвристические и статистические методы на практике работают не так, как в маркетинговых статьях и заявлениях, запугивающих пользователей): Mikko Hypponen из F-Secure пишет в Wired, что код нашумевшего вируса Flame находился в базах разработчиков антивирусов более двух лет, но никто его не исследовал.

Первый кириллический домен РФ работает уже больше двух лет. Сейчас в нём зарегистрировано чуть более 800 тыс. имён. Что, вообще говоря, немало для подобного домена. Тем не менее, тенденции пока что не самые радужные. Вот пара графиков (исходники доступны на stat.nic.ru):

1. Динамика новых регистраций (в январе – всплеск, теперь опять всё затухает):

2. Динамика продлений регистраций:

Всплеск на двух графиках – это такой след попыток “прокачать” зону. Однако после прокачки напор снова быстро улетучивается. Как и прежде, большой вопрос: будет ли миллион регистраций?

Кстати, рассматривая развитие .РФ, нужно учитывать такой момент: ждать весомых преимуществ от использования новинки в области интернет-технологий массовый потребитель готов год-два, а потом бесполезную “новинку” забросят куда подальше. К сожалению, у кириллической зоны преимуществ особых нет, а вот дополнительных проблем с использованием – хоть отбавляй.

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

Понятно, что есть РЛС разного базирования и мощности. Так как бомбардировщики летают высоко, то наземные станции могут, чисто геометрически, наблюдать их с больших дистанций (многие сотни километров). Но если радиолокационную заметность самолёта удалось радикально снизить, то даже мощные наземные станции могут оказаться не эффективными. По крайней мере, дистанция обнаружения уменьшается. То же самое можно сказать о самолётах ДРЛО и, тем более, об очень удобных орбитальных радарах. Впрочем, действительно малозаметный бомбардировщик, скорее всего, должен летать медленно, с дозвуковой скоростью, иначе сопровождающие полёт атмосферные эффекты позволят его обнаруживать.

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

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

Дирижаблю самолёта не догнать. Но догонять и не требуется. Можно наметить районы и направления, которые относятся к интересным для патрулирования бомбардировщиком. Или, скажем, нахождение бомбардировщиков в этих районах представляет опасность. В этих районах размещаются и постоянно дежурят дирижабли с мощной аппаратурой слежения. Основное преимущество в постоянстве присутствия. Правда, схема не обеспечивает мониторинга движения бомбардировщика в режиме онлайн за пределами зоны охвата дирижаблей, но можно более или менее точно сказать, в каких районах бомбардировщика нет. Тоже полезно.

Бомбардировщику нужна дозаправка. Танкер оказывается дополнительной точкой привязки – можно мониторить его перемещение, если только он не сделан ещё менее заметным, чем бомбардировщик. Встреча с танкером позволит обнаружить сорвавшийся с глобального сопровождения самолёт.

Кстати, при наличии развитой агентурной сети, заметную помощь окажут сообщения о подготовке к вылету и о вылете с аэродрома (это если не удалось получить сразу копию полётного задания). То есть, древние традиционные методы никто не отменял. И, да, аэродромы можно мониторить со спутников.

Наверное, есть ещё какие-то методы и схемы.

На dns.dxdt.ru я добавил рейтинг (по числу доменов) серверов имён, почтовых серверов и IP-адресов. Довольно показательная картина.

ICANN продолжает удивлять собщество. Теперь у них скандальчик с публикацией в открытом доступе данных зявителей на New gTLD.

В опубликованной ICANN таблице заявок на новые домены верхнего уровня есть поле Location, обозначающее связь заявки с географией. Выборка по этому полю со значением RU показывает восемь российских заявок. При этом, сюда входят не все кириллические заявки, например, не входит домен .католик, заявку на который подают из Ватикана. Впрочем, вернёмся к росийским доменным идеям, вот список в формате “домен – заявитель” (на английском, я просто взял строку из базы):

.ДЕТИ
The Foundation for Network Initiatives “The Smart Internet”

.МОСКВА
Foundation for Assistance for Internet Technologies and Infrastructure Development (FAITID)

.РУС
Rusnames Limited

.GDN
Joint Stock Company “Navigation-information systems” – это НИС ГЛОНАСС, если кто не в курсе.

.MOSCOW
Foundation for Assistance for Internet Technologies and Infrastructure Development (FAITID)

.SKOLKOVO
Fund for Development of the Center for Elaboration and Commercialization of New Technologies

.TATAR
Limited Liability Company “Coordination Center of Regional Domain of Tatarstan Republic”

.YANDEX
YANDEX, LLC

А интересно тут то, что на домен .GDN подано две заявки, вторая – от Guardian News and Media Limited, из Великобритании. Во как.

В ICANN наподавали немало заявок на разнообразные новые домены. Сегодня опубликован список.

Update: сервис, описанный в этой заметке, более не доступен.

Сделал вот сервис dns.dxdt.ru – позволяет искать сведения об адресации, связанные с DNS. Бета-версия. За веб-интерфейсом скрывается база данных из примерно 13 млн документов, которые были получены при помощи опроса доменных зон .ru, .su, кириллической .рф.

Зачем нужно обходить доменные зоны? Давайте вспомним, что DNS работает “напрямую”, то есть в ответ на запрос о “буквенном имени” выдаёт IP-адрес, адрес почтового сервера или ещё что-то. Получить ответ на обратный запрос – “какие домены используют указанный IP-адрес?” – средствами DNS, в общем случае, нельзя. Есть специальные исключения, обратные зоны, но это совсем другая история. Поэтому для того, чтобы провести какой-то поиск, найти “соседей” данного сайта, вычислить общие черты, ещё что-то исследовать – нужно предварительно построить слепок сегмента DNS, опросив серверы имён и сохранив результаты. Собственно, отсюда и получаются все эти миллионы документов.

Как работает dns.dxdt.ru? Интересно было попробовать современные решения. Поэтому в качестве СУБД выбрана MongoDB – это NoSQL СУБД. Сам сервис использует два сервера минимальной конфигурации из амазоновского EC2: на одном работает MongoDB, это, так сказать, “бекэнд”, на втором – связка Apache, PHP, Memcached, это, стало быть, “фронтэнд”. Была идея использовать на “фронтэнде” Ruby, но данный язык, вполне ожидаемо, оказался чудовищно медленным. Отказался. Memcached кэширует не ответы БД, а форматированные результаты выдачи (то есть, итоговые HTML-страницы), что сильно ускоряет работу на повторяющихся запросах. При этом, впрочем, остаётся проблема с доставкой клиенту больших по объёму страниц: некоторые запросы генерируют десятки и сотни тысяч строк в ответе (таковы, например, запросы об ns-ах крупных регистраторов доменов).

Ещё одна особенность: кириллические домены полностью обрабатываются на стороне клиента, Javascript-ом в браузере. То есть, сервер отдаёт и принимает только классическое представление (ASCII), в котором многоязычные имена выглядят как строки с префиксом “xn--“. По-моему, это, прежде всего, идеологически правильно, так как всё “доменное многоязычие” существует именно на клиентском уровне, внутри DNS никаких Unicode-строк нет. Кроме того, реализация многоязычных имён на серверной стороне, вполне предсказуемо, потянула за собой кучу дополнительных задач – преобразование кодировок, контроль этих преобразований, ловля ошибок, обработка “нестандартных” символов и так далее, и тому подобное.

На следующем шаге планирую добавить в dns.dxdt.ru вывод некоторой статистики, обработку MX-ов. Наверное, что-то ещё. Сервис довольно специфический, но всё равно: вопросы, предложения, пожелания – всячески приветствуются в комментариях.

В 2012 году на roem.ru сообщают: “MD5 больше не надёжен”.

Вообще, о том, что MD5 не является стойким вариантом для преобразования паролей с целью их сохранения, стало известно примерно через пару лет после разработки MD5 (1991). Но, спустя ещё, примерно, два десятка лет – “ненадёжность” MD5 остаётся открытием. В принципе, это объясняет и то, почему разработчики продолжают MD5 применять везде, где только могут.

Очередной День IPv6 отмечают сегодня, 6 июня. Про новый протокол, малодоступный для рядового пользователя Интернета, я писал раньше, поделюсь некоторыми ссылками:

• “Перечислимость” IP-адресов;
• Техническое: практика IPv6;
• Воскресный юмор: как исчерпать адресное пространство IPv6.

Чуть больше года работает тестовый сервер IPv6/IPv4: ipv6.nic.ru, поднятый к прошлому всемирному “переходу” на новый протокол; статистика там накоплена не очень большая, так как, понятно, посещаемость оставляет желать лучшего, но всё равно видно, что IPv6 – пока не популярен.