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

Опубликовано исследование распространения CMS в Рунете, включающее, кроме того, анализ использования современных веб-технологий (HTML5, различные DOCTYPE и др.). Выполнено аналитической группой RU-CENTER.

С большим отрывом побеждают Joomla! и WordPress, Drupal – третий. Там, по ссылке, опубликовано описание методики и ещё куча интересной статистики.

Координационный и технический центры российских национальных доменов готовятся к введению DNSSEC в .ru – это основной домен из трёх (su, рф, ru). Вот, пишут, что сгенерировали ключи и положили их на изолированный компьютер (air gap, да). Подписать .ru обещали до конца этого года. Так что можно, в принципе, готовить серверы и свои зоны. (Я dxdt.ru уже подписал; вот значение для DS – 12E833887648F73B80E06CC86252E025FFE5F75F.)

Существует технология DANE, позволяющая использовать DNSSEC для контроля достоверности SSL-сертификатов. Пока что, технология эта далека от практического внедрения, хоть и выглядит очень привлекательно. Существенный вклад в формирование этой привлекательности вносит тот факт, что DANE позволяет придать столь популярным “самоподписанным сертификатам” новый статус, привязав их к цепочке доверия DNS. Конечно, только если в домене уже работает DNSSEC.

У DANE, впрочем, есть некоторые особенности, – скорее, негативные, – которые связаны с тем, что для обеспечения управления доверием используется DNS. Причём, фактически, важную роль играет административная структура этой системы, а не чисто техническая.

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

Дальнейшие шаги понятны: генерируется “самоподписанный” сертификат для атакуемого домена (сайта), вносятся записи DANE в доменную зону, и всё – готово: HTTPS-соединение качественно перехвачено.

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

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

(Напомню, что в спецификации DANE учтены случаи использования SSL-сертификатов, выданных удостоверяющими центрами, которые могут входить в существующую “браузерную” инфраструктуру; а могут и не входить, да.)

График, отражающий отключение Интернета в Сирии:

Более подробная информация – на сайте Renesys.

Пишут, что в Сирии Интернет отключен, практически на 100%.

Для дальнейшего тестирования DNSSEC и сопутствующих инструментов я сделал пару сломанных зон. Особенно радикально сломана dotsu.su – там в зоне .su указан зарезервированный код алгоритма для DS-записи, а внутри зоны содержатся “сильно кривые” записи DNSKEY. Так, при попытке обработки dotsu.su – успешно падал онлайн-инструмент VeriSign DNSSEC debugger (http://dnssec-debugger.verisignlabs.com/), сейчас, после того, как я написал в техническую поддержку, всё исправили.

Есть вторая зона broken.nox.su, третьего уровня, там пока просто отсутствуют DS-ы в зоне уровнем выше (nox.su), что является более мягким вариантом. Update: теперь для broken.nox.su добавлена DS-запись, которая не соответствует никакому ключу в зоне (ключей там нет, собственно), так что адреса в broken.nox.su с DNSSEC резолвиться не должны.

Вообще, можно с уверенностью сказать, что основные проблемы с DNSSEC-ом будут даже не в том, что зоны станут подписывать криво, а в том, что внедрение разных сложных вспомогательных инструментов даёт новые направления для атак. И скоро мы увидим множество таких атак, в том числе, и на регистраторов.

ICANN ведёт страницу со списком мировых регистраторов доменов, поддерживающих DNSSEC. Список, мягко говоря, очень короткий. Зато там наконец-то появился первый российский регистратор – RU-CENTER (со скромным, пока что, перечнем поддерживаемых доменов: .com, .net, .su).

Пару десятков лет назад у меня был домашний “286-й компьютер” (IBM-совместимый, как это тогда называлось), оснащённый жестким диском в 40 Мб (прописью: мегабайт). Сейчас я такой же объём данных получаю с сервера в Европе, через Интернет, за пять секунд (буквально – менее пяти секунд). То есть, весь тот старый жёсткий диск, на котором много чего помещалось. Тоже на домашний компьютер, который находится, в масштабах глобальной географии, примерно на том же самом месте. Это и есть показатель развития информационных технологий, а вовсе не то, что аналогичные по назначению жёсткие диски теперь где-то в 25 тысяч раз большего объёма.

Многие спрашивали про поддержку DNSSEC российскими регистраторами. Вот, буквально только что, запустили такую поддержку RU-CENTER и R01. Причём, RU-CENTER поддерживает DNSSEC и для зон .com и .net (R01 – пока только .su).

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

Подробнее про DNSSEC на практике можно почитать на странице, размещённой под “демонстрационным доменом” nox.su, который, конечно, DNSSEC поддерживает.

Если у кого есть вопросы по данной технологии – пишите, можно почтой (адрес справа на этой странице), можно в комментарии.

На сайте Internet Society ведётся список ресурсов, поддерживающих новую технологию DANE. Сайтов там пока что не очень много. Это хорошо объясняется тем, что поддержка DANE пока отсутствует в браузерах. Есть только один плагин для Firefox, да и то – в альфа-версии. Большая проблема. Без браузерной поддержки DANE никому не нужен. Без DANE – DNSSEC теряет заметную часть технологической привлекательности, потому что только благодаря привязке к сайтам DNSSEC можно продвинуть на клиентскую сторону.

Согласно современной реальности Интернета, прорывом был бы качественный плагин для майкрософтовского браузера IE. У меня нет уверенности, что подобный плагин возможен для IE, так как я недостаточно знаком с архитектурой этого браузера. Если кто-то может рассказать подробности, то, пожалуйста, выскажитесь в комментариях. Ниже, я опишу логику работы плагина, вдруг, кто-то захочет его реализовать (что было бы замечательно).

Итак, DANE позволяет разместить в DNS отпечаток SSL-сертификата и проверить достоверность соответствия этого отпечатка домену при помощи DNSSEC. Для проведения проверки требуются: значение специальной записи из DNS и сертификат, предъявляемый веб-сервером. Сличение проводится, грубо говоря, по имени хоста. То есть, отпечаток из DNS для заданного хоста должен соответствовать отпечатку, вычисленному по полученному сертификату. Более подробное описание части, касающейся DNS, есть в записке про DANE.

Соответственно, плагин для браузера должен вмешиваться в процесс установления соединения по HTTPS с веб-сервером, получать отпечаток ключа сертификата, предъявляемого сервером и сверять этот отпечаток с данными, полученными из DNS, если их удалось получить и подтвердить DNSSEC-ом, конечно. Дальнейшее поведение плагина зависит от того, каковы результаты проверки:

• если валидный отпечаток из DNS совпадает с сертификатом, то браузер должен показать некий дополнительный флаг, означающий, что связка сертификат-сайт проверена DNSSEC. Если при этом сертификат самоподписанный или выдан неизвестным браузеру удостоверяющим центром (УЦ), то нужно подавить предупреждение браузерной системы безопасности (а можно ли это сделать в IE?);
• если отпечатки не совпали, то нужно, наоборот, выдать предупреждение системы безопасности, даже если сертификат валидный и подписан доверенным УЦ;
• если данные, полученные из DNS, не прошли проверку подлинности, а всё остальное – совпадает, то, опять же, нужно выдать предупреждение.

Плагину придётся самостоятельно проводить проверку подписей DNSSEC и извлекать их из DNS. В общем, задача не самая простая, но, вероятно, решаемая. Это я к тому, что, может, кто-то возмётся за реализацию.

Занятная работа, посвящённая исследованию внутреннего устройства иранского адресного пространства Интернета. Автор обнаружил, что внутри Ирана “слишком широко” используются “немаршрутизируемые” адреса (192.168.0.0 и др.), на базе которых, на межсетевом уровне, построен некий скрытый национальный интранет.

(The Hidden Internet of Iran: Private Address Allocations on a National Network.)