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

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

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

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

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

Часто ссылаются на HTTPS, как на недоступный для подобного анализа протокол. Да, формально, HTTPS предоставляет зашифрованный канал связи. Но в реальности есть ряд методов, позволяющих, на практике, всю эту защиту перевести в разряд мнимых. Устройства для анализа сетевого трафика, находящиеся между пользователем и тем ресурсом, с которым он соединяется, давно умеют перехватывать сессию HTTPS в момент её установления, на лету генерировать SSL-сертификат для соответствующего ресурса и – пожалуйста, трафик можно прослушивать. Естественно, тут есть проблема с тем, что сертификат, выпущенный перехватывающим устройством, должен успешно помещаться в цепочку доверия браузера – иначе браузер выдаст предупреждение.

Но, во-первых, массовый пользователь игнорирует подобные предупреждения браузера, “заставляя” тот продолжить использование веб-сайта. Во-вторых, нет особых гарантий того, что удостоверяющие центры, входящие в список доверенных браузера, не участвуют в работе систем DPI. Собственно, вокруг второго момента, который, вообще-то, давно известен, сейчас разгорелся нешуточный сыр-бор. В случае, если автоматический инспектор трафика использует для генерации своих “перехватывающих” сертификатов сертификаты доверенного УЦ (не обязательно корневой, годятся промежуточные), то обычный пользователь браузера даже не увидит предупреждения, не заметит подмены. (Кстати, есть неплохой плагин для Firefox, позволяющий следить за тем, как браузер оперирует сертификатами – Certificate Patrol.)

Заметьте, что если у провайдера работает добротная система анализа трафика, то можно блокировать этот трафик не только по контенту или по адресам, но и по типу трафика, используя белый список. Соответственно, если поток не удаётся разбирать и классифицировать, то его можно заблокировать. Естественно, этот принцип работает и для HTTPS – если клиент не стал соединяться с перехватывающим трафик узлом, то соединение вовсе блокируется. Через настроенную подобным образом сеть не пройдёт канал VPN, даже если, скажем, он использует нестандартные порты (например, я использую собственный VPN, работающий по TCP, через 80-й порт).

Проблему передачи шифрованных данных через такую “фильтрующую сеть” можно решить, используя стеганографию – данные закрытого канала помещаются внутрь маскирующего, имитирующего “обычную” работу с рядовым веб-сайтом. Такие решения известны. Из новинок – вот есть Telex. Понятно, подобный канал будет медленным.

Кстати, фокусам с подменой SSL-ей отчасти может помешать внедрение технологий вроде DANE. Но нужно учитывать, что, в теории, тот же DANE, если говорить о типичном пользователе Интернета, перехватывается аналогичными SSL методами, здесь лишь сильно сужается круг тех, кто может осуществить такой перехват. Что, логичным образом, возвращает нас к мысли о реальных причинах шума, высказанной в самом начале заметки.

Под брендом регистратора R01 заработал бесплатный сервис WhoisHistory.ru, позволяющий просматривать административную и техническую историю использования доменов .ru, .su, .рф. Отображаются изменения администраторов, контактных данных, серверов имён и другой информации. Есть расширенный поиск доменов по различным критериям, например, по NS-ам, по IP, по организации, регистратору и так далее.

Думаю, это первый бесплатный сервис подобного типа для российских доменов. Сайт: whoishistory.ru.

В свете падения известных хостингов, которое сейчас обсуждают, поделюсь описанием того, как работает и где размещается dxdt.ru. Сайт я разместил на амазоновском EC2, на виртуальном сервере (сервер типа Small Instance). Операционная система Amazon Linux (это, по сути, Red Hat). Веб-сервер – Apache 2.2. Непродолжительное время использовал nginx в качестве обратного прокси к Apache, но, пока что , особого смысла в nginx, конкретно для dxdt.ru, не вижу: монструозный Apache справляется с небольшим трафиком.

БД – MySQL, на том же сервере; иногда с аппетитом кушает память. PHP + APC (это “ускоритель” PHP, как известно) + WordPress + кэшируюший плагин W3 Total Cache (очень полезный плагин оказался).

Есть поддержка HTTPS, но я использую собственный корневой сертификат (и это правильно, для данной модели), так что попытка обратиться по HTTPS стандартным браузером приведёт к ошибке/предупреждению. Понятно, что HTTPS предназначен для админки WordPress-а (WP). Тут надо заметить, что разработчики WP никак не допилят поддержку HTTPS, поэтому в некоторых случаях страницы (не принадлежащие к админке) генерируются с элементами, адресуемыми по HTTP (обычно, это картинки). Возможно, есть какой-то плагин, решающий эту проблему.

В целом, WP – неплохая CMS. Есть планы (о которых мне периодически напоминают) переписать dxdt.ru руками на специальный “движок”, отказавшись, наконец, от PHP. Интерес тут чисто спортивный. В качестве снарядов для данного спорта я сейчас рассматриваю связку Python + Django + MongoDB + какой-то не-Apache (nginx?). Но это планы, да.

Опыт использования амазоновского хостинга для dxdt.ru положительный. Доступность хорошая. Ресурсов хватает. Гибкости тоже. Нет трудностей с IP-шниками (кстати, важный фактор!). Например, удалось оперативно и без всяких проблем настроить обратную зону для IP-адреса dxdt.ru (это нужно для отправки почты с сервера) и всё такое прочее. Преимущество амазоновского сервиса в том, что тут предоставляется инфраструктура, то есть можно самостоятельно быстро поднять нужные серверы, что-то настроить, переключить адреса, ну и так далее. Это уровнем выше аренды обычного виртуального сервера, и удобнее, чем один физический выделенный сервер. Вообще, я амазоновским EC2 пользуюсь несколько лет, но для совсем других задач – сайты раньше там не хостил, а оказалось, что и для этого весьма хороший вариант. Кстати, домен dxdt.ru я поддерживаю тоже на паре NS-ов, находящихся в EC2 (это не амазоновский DNS, а виртуальные серверы с BIND-ом – всё жду, когда же КЦ и ТЦИ доделают DNSSEC в .ru, чтобы быстро внедрить поддержку, да, видно, нескоро это будет).

Вот.

Update (18/04/2014): эта записка некоторое время не обновлялась, а между тем, ещё в декабре 2012 года, в домене RU внедрили поддержку DNSSEC; конечно, домен dxdt.ru был подписан одним из первых.

Update (24/11/2014): c 21 ноября 2014 года dxdt.ru возвращает страницы только по HTTPS – этот безопасный протокол стал единственным для работы с сайтом.

В Интернете публикуют файл с пользовательскими паролями, стащенными, как пишут, из некоторого сервиса Yahoo! Сейчас пароли меняют. Традиционная статистика по лидерам среди пользовательских паролей (посчитал по исходному файлу, указаны пароли с числом вхождений больше 128):

123456:1667
password:780
welcome:437
ninja:333
abc123:250
123456789:222
12345678:208
sunshine:205
princess:202
qwerty:172
writer:164
monkey:162
freedom:161
michael:160
111111:160
iloveyou:140
password1:139
shadow:134
baseball:133
tigger:132
1a1a1a1b:131

1a1a1a1b – неплохой вариант, кстати. Интересно, если перечень реальный, то, после того, как пользователей попросят сменить пароли, сильно ли изменится рейтинг? Например, вместо 123456 – в лидеры может выйти 111111. Какой вообще смысл просить менять пароли, если политика позволяет использовать слабые варианты? Которые, к тому же, хранятся в открытом виде.

Обновилась БД на dns.dxdt.ru. Впрочем, пока что наиболее активный посетитель проекта – Google bot: очень активно ходит по внутренним ссылкам. Между тем, dns.dxdt.ru – инструмент, на мой взгляд, полезный, хотя и специальный, требующий понимания того, что ищем. Посмотрите, вот ссылка на занимательный кластер “фармацевтических” доменов (легальных, например, упса.рф). Для них в DNS зачем-то указаны “дефектные” IP в A-записях: 0.0.0.0, 1.1.1.1 и т.п.

Всяких занятных кластеров много. Может, сделать какую-нибудь автоматическую-тематическую кластеризацию?

Кстати, для провайдера, заблокировать доступ к сайту по IP-адресу – это самое простое решение, потому что IP-маршрутизация большей частью работает, примерно, на аппаратном уровне. То есть, очень быстро и прозрачно. А вот блокирование на уровне прикладных протоколов (DNS, HTTP), позволяющее сделать блокировку более избирательной – это уже сильно другая задача. Тут требуется анализ содержимого пакетов, а не заголовков, который тянет за собой дополнительное ПО и заметные вычислительные мощности.

Хотя, надо заметить, блокирование по прикладным протоколам математически выглядит куда более правильным – ведь для чтения сайтов используют именно их. В плане реализации особенно занимательно выглядит инспектирование HTTPS, да. Ну а верный способ построить эффективную систему, это строгий контроль пользовательского ПО, служащего для просмотра Интернета.

Технология под названием 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 выдаёт предупреждение о “плохом” сертификате. Надеюсь, что по мере развития технологии, всё нормализуется и будет один стандарт.

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

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

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

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

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

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 наподавали немало заявок на разнообразные новые домены. Сегодня опубликован список.