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

Mozilla опубликовала новую политику управления корневыми сертификатами, входящими в дистрибутив браузера. В новой версии включили пункт, ставший реакцией на скандалы с удостоверяющими центрами (пункт 3 в разделе Enforcement Policy). Речь там о потенциальном исключении корневого сертификата УЦ из браузерного списка доверенных, если станет известно, что удостоверяющий центр выпустил сертификат для того или иного домена не убедившись, что получатель сертификата действительно этим доменом управляет.

Опубликованный текст политики, в итоге, содержит ссылку на требования CA/Browser Forum (CAB-форум – это сообщество, в рамках которого производители браузеров взаимодействуют с УЦ), а не прямое упоминание процедур проверки контроля над доменом. Но, в принципе, требования CAB-форума как раз и состоят в необходимости проведения такой проверки. Так что, по крайней мере формально, удостоверяющий центр, содействующий выпуску SSL-сертификатов для “чужих доменов”, рискует вылететь из списка доверенных. (Напомню, что упомянутые сертификаты служат для перехвата HTTPS-трафика, адресованного любому домену, в прозрачном для пользователя режиме.)

Между тем, The Old Reader, который я упоминал в заметке про замену Google Reader, – похоже, всё ж завершает своё существование: проект закрывают сами разработчики, у которых нет больше сил на его сопровождение и развитие. Цитата:

Last week difficulty level was changed to “hell” in every possible aspect we could imagine, we have been sleep deprived for 10 days and this impacts us way too much.

(На прошлой неделе уровень сложности поменялся на “Ад” во всех возможных аспектах, которые мы могли вообразить, мы не спали десять дней, это слишком сильно на нас повлияло.)

Такое вот продолжение проекта получилось.

Кстати, для Рунета мне известны три источника статистики использования на сайтах систем управления контентом (CMS):

1. CMS на Stat.nic.ru – реализуется в RU-CENTER, здесь есть динамика по месяцам, данные даны с декабря 2013 года, анализируются семь CMS: Joomla!, WordPress, Drupal, MODx, “1C-Битрикс”, NetCat, UMI.CMS. Теория и практика, стоящие за этой статистикой, подробно описаны, для соответствующего робота создана информационная страница. (Да, оговорюсь, на всякий случай: я имею прямое отношение к этому проекту.)

2. CMS на StatOnline.ru – проект REG.RU, есть динамика по месяцам, данные даны с апреля 2013 года. CMS здесь заявлено гораздо больше, а именно – 20. Описание методики, какие-то подробные статьи с анализом собранной статистики CMS, найти пока не удалось. Это не очень хорошо. Тем не менее, числа, по совпадающим CMS, близки к полученным в исследованиях Stat.nic.ru.

3. iTrack.ru – рейтинг iTrack, появившийся самым первым из упомянутых в этой записке. Динамики по месяцам нет, исследование, насколько можно понять, проводится редко. Недавно появился отчёт за первое полугодие 2013 года. Числа близки к показателям двух других источников. На сайте есть очень краткое описание методики. К сожалению, это описание содержит досадные технические неточности, которые авторы никак не исправят. Например, там фигурирует такая фраза: “В ходе исследования учитываются домены, ответившие в течение 20 секунд на запрос по адресу http://domain.ru.” Очевидно, домены не могут отвечать на HTTP-запросы, это делает веб-сервер.

Есть ещё рейтинги CMS, составляемые при помощи опроса веб-студий. Но это совсем другая выборка, мало что говорящая о технологиях, реально использующихся в Рунете.

Роскомнадзор утвердил “Рекомендации по ограничению операторами связи доступа к сайтам в сети Интернет с запрещенной информацией”. Сами рекомендации тоже опубликованы на сайте (формат Word .DOC – хотя, конечно, хотелось бы видеть RTF, ну да ладно). Кратко: блокировать рекомендовано не по IP, а по URL, только “на сетях доступа”, то есть, за исключением транзитного трафика. Выделение URL должна проводить система DPI. Собственно, вариант весьма разумный, и, да, это те рекомендации, которые публиковались раньше. Теперь посмотрим, как их будут внедрять.

(А VPN, HTTPS и прочие штуки – давайте оставим за скобками.)

Кстати, для сбора и чтения RSS-лент, в качестве замены закрытому Google Reader, я установил Tiny Tiny RSS (TT-RSS). Пока что этот инструмент, который нужно “хостить” самостоятельно, выглядит очень неплохо. Установился без проблем, настройка также трудностей не вызвала. Работает под Apache+PHP+MySQL, на виртуальном сервере под Linux. Пакет обладает приличной гибкостью, можно настроить под свои привычки. Например, Tiny Tiny RSS умеет генерировать ежедневный дайджест из сообщений RSS-лент и присылать его почтой. На мой взгляд, одна из самых полезных функций.

До того, как установить TT-RSS, я некоторое время использовал The Old Reader – это “внешний” сервис, который выглядел весьма привлекательно, так как, фактически, просто повторял полезные функции Google Reader. К сожалению, The Old Reader сломался. Совсем. Сейчас они показывают котиков. (Это такая находка, недурная, надо сказать: на странице, сообщающей о недоступности сервиса, размещаются изображения котов. Проблема в том, что котики там показываются уже много дней, так как разработчики хрестоматийным образом потеряли свои базы данных, и, похоже, проект на этом завершился. Жаль.)

Update: как подсказывают в комментариях, The Old Reader вернулся. Это очень хорошо. Если разработчикам удастся достичь некоторой минимальной разумной надёжности, то этот проект можно будет рекомендовать.

В ICANN (это, если кто не помнит, корпорация, управляющая распределением адресных ресурсов Интернета) готовят новые правила для регистраторов доменов. Помимо прочего, там есть ряд пунктов, прямо требующих от регистратора проверки предоставленных потенциальным администратором домена контактных данных.

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

(Эффективность подобных методов, если рассматривать их как средство снижения степени анонимности при регистрации доменов, – это совсем отдельная история, тут интересна общая тенденция.)

Опять наблюдается волна запросов с попытками подбора паролей к WordPress. Много IP-адресов. Запросов, если не фильтровать, – тысячи. Судя по всему, это повтор аналогичной атаки, проходившей в апреле. Схема та же. Сперва бот определяет имена пользователей, существующие на сайте. Делается это при помощи отправки запросов в форму восстановления паролей, с разными логинами. WordPress возвращает разные ответы, в зависимости от того, существует ли логин (имя пользователя). После того, как построен список имён пользователей, начинается перебор паролей для них.

Бороться с этим можно разными способами. На мой взгляд, самый подходящий вариант – интеллектуальное блокирование сканирующих IP-адресов, например, при помощи fail2ban (или аналогичного инструмента).

Занятное сейчас время в истории российского Интернета. Больше года назад мы с Артемием Ломовым написали для “Доменных имён” статью “Сценарии конца Интернета”, я уже как-то приводил на неё ссылку. В качестве первого сценария конца в статье приводится сбой “Красной кнопки” – механизма, призванного блокировать отдельные сайты. Процитирую пару моментов:

Предположим, что такую кнопку создали. Неважно как. […] При создании кнопки не предусмотрели всех мер по ее защите, по исключению ложного срабатывания. Еще бы! Кнопку конструировали для того, чтобы отключить интернет-ресурсы, и всякие излишние меры предосторожности тут вредны — вдруг в ответственный момент они помешают?

В общем, однажды кнопку включат для того, чтобы заблокировать один интернет-ресурс, но в результате срабатывания технологического механизма заблокированным и отключенным окажется весь Интернет. «У-упс! » — вежливо произнесет оператор кнопки, обозначив окончание очередной эпохи.

Думали, фантастика. Но уже в мае этого года из-за серьёзной архитектурной ошибки в реализации блокирования сайтов “Ростелеком” на некоторое время закрыл доступ к “Яндексу”. То есть, первый сценарий уже заиграл.

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

Сценарий может подкорректировать вмешательство государств, которые […] запретят использование файлообменных протоколов и заодно социальных сетей, обяжут провайдеров блокировать соответствующие виды трафика и, например, разрешать доступ только по «белым спискам». Не ограниченное фильтрами использование Интернета вообще автоматически приравняют к «нарушению копирайта», не размениваясь на уточнения, и обычные пользователи потеряют ко всему этому технологическому безобразию интерес.

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

Историческое время.

P.S. Кстати, с апреля этого года я больше не являюсь главным редактором “Доменных имён”, но остался в редколлегии и веду в журнале раздел, посвящённый информационной безопасности.

Как я некоторое время назад писал, на сайте Роскомнадзора опубликованы технические рекомендации по методам осуществления блокировки доступа к ресурсам Интернета. Сегодня рекомендации обновили. Смотрим, какой метод описан в документе:

Рекомендовать использование следующей технологии для реализации блокирования:
[…]
b. Трансляция с помощью запросов в DNS доменного имени в IP-адрес

c. Создание и распространение по системе маршрутизации сети доступа провайдера специального маршрута для данного IP-адреса, направляющего трафик в специальный анализирующий сегмент

d. Проведение анализа проходящего через анализирующий сегмент сервер [трафика] (в исходном документе, видимо, опечатка – АВ), выявление запросов к URL, содержащихся в списке блокировки, уничтожение данных запросов или перенаправление их на специальный ресурс, уведомляющий о факте блокировки.

То есть, IP-адрес, соответствующий блокируемому домену, берётся из DNS, трафик, поступающий на этот адрес, отправляется в систему DPI, которая выбирает из пользовательского потока запросы на конкретные адреса, внесённые в список блокируемых. В случае с HTTP – это, например, GET. В целом, выглядит логично.

(Да, понятно, что есть куча специальных случаев, но это другая история.)

В основе криптографии, используемой в TLS (транспорт для HTTPS), лежат вовсе не абсолютно стойкие системы. Конечно, предположение о том, что кто-то тайно построил мощный квантовый компьютер и теперь легко вскрывает ключи RSA длиной до 4096 бит – слишком фантастично. Но можно предположить, что специализированные агентства, которые всегда имели мощную исследовательскую базу, научились резко снижать вычислительные затраты, нужные для факторизации больших чисел (это, как известно, “ломает” RSA). Конечно, быстрая факторизация – не единственный способ атаки на RSA, есть немало других, тоже вычислительно сложных.

Естественно, современная реализация TLS использует сеансовые ключи, генерируемые тем или иным алгоритмом, реализующим протокол Диффи-Хэллмана. Хитрость этого протокола в том, что даже если атакующий получил секретный ключ, используемый сервером, он не сможет расшифровать с его помощью сеансовый ключ. Но задачи, лежащие в основе и RSA, и схемы Диффи-Хэллмана – математически связаны между собой. Поэтому, если уж предположить, что некое агентство сумело сделать прорыв в этой области, то, вероятно, такой прорыв коснулся и той, и другой задачи. И вот поэтому появился смысл для записи сеансов HTTPS (и не только их), чтобы потом, с некоторой задержкой, расшифровать интересующие фрагменты трафика.

Известно, что по каналам Интернета ходит большой объём пользовательского трафика, который, при непрерывной записи, сложно полностью хранить (в течение длительного времени). Предположим, что гигабитный канал, имеющий усреднённую загрузку 80%, генерирует около 290 гигабайт “полезного” трафика в час. Это примерно 7 терабайт в сутки, то есть, если мы используем хранилище данных в 1000 терабайт (несколько тысяч жёстких дисков, несколько стоек в дата-центре), его не хватит и на полгода.

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

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

Конечно, такая система, записывающая большие объёмы трафика, должна иметь некий кеш, в который попадает необработанный трафик: детально разбирать трафик на лету – слишком сложно. А основная проблема кроется в том, как именно за разумное время сопоставлять пользовательские действия с накопленной базой объектов. Причём, трудность не в самом поиске в базе, а в идентификации отдельных пользователей.