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

Занятно: браузер Chrome в Рунете выбрался в лидеры, LiveInternet насчитали аж 18.6% (первое место). Судя по графикам, Chrome вытесняет IE. Как и предполагали ещё в прошлом году, одна из причин в отсутствии внятного браузера от Microsoft под Windows XP: IE9 там не работает. Но это только одна из причин, да.

Спустя примерно месяц, я вновь собрал SSL-сертификаты с серверов, на которые указывают домены .ru. Методика описана в прошлой записке по этой теме. Кратко повторю основные моменты: на первом этапе делается попытка определить адрес сервера (A-запись) для каждого из делегированных доменов (учитывая www.) в зоне .ru; из найденных серверов с уникальными IP выбираются те, у которых открыт 443-й порт (https); на заключительном этапе каждый из отобранных серверов опрашиваются на предмет SSL-сертификатов путём открытия https-сессии; собранные сертификаты разбираются при помощи OpenSSL.

В результатах “много цифр”, поэтому прячу под “Читать полностью”.

Читать полностью

Записка про DNSSEC в реальности Интернета получила хорошее продолжение.

Благодаря поддержке RU-CENTER, – персональное спасибо Павлу Ильичеву, – содействию ФРИ (Фонд Развития Интернет – администратор домена SU) и ТЦИ (Технический Центр Интернет – оператор реестра), домен nox.su, который я привожу в пример в прошлой записке по теме, подписан по всем правилам. Cоответствующая DS-запись внесена в зону .su без проблем. (Для того, чтобы посмотреть на результат, можно воспользоваться всё тем же инструментом от VeriSign.)

Так что технология DNSSEC в домене с особым статусом SU начала разворачиваться на практике. Это хорошо. Насколько я понимаю, nox.su стал первым подписанным доменом второго уровня в .su. Зато теперь не нужно перебираться в .org с экспериментами: .su, при всех особенностях, вполне себе российский домен.

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

К сожалению, в домене ru DNSSEC появится неизвестно когда, но точно нескоро. Другой российский (по факту) домен – su, – хоть и заявлен недавно на конференции ICANN как поддерживающий DNSSEC, на практике, насколько я смог выяснить, не позволяет воспользоваться защитными механизмами. Записи об su в корне DNS подписаны, но в самой этой зоне мне не удалось найти ни одного подписанного домена второго уровня. Более того, не подписан даже домен администратора SU – fid.su. Для рядового же пользователя проблема в том, что, на практике, отсутствует механизм “привязки” подписанной зоны второго уровня к ключам домена SU.

(Addon (17/11/11): как пишут из ТЦИ, реестр SU поддерживает работу с DNSSEC, но регистраторы пока не реализовали свою часть. Ждём.)

Вообще, подписать саму зону можно не прибегая к услугам администратора домена верхнего уровня (см., например, nox.su, который я подписал в порядке эксперимента – сами записи в зоне подписаны, но цепочка рвётся в .su, разместить там нужные данные сейчас не представляется возможным). “Привязка” доменов к единой цепочке выполняется с помощью специальных DS-записей (Delegation signer), вносимых в зону, уровнем выше удостоверяемой, для построения иерархии, ведущей к корневому ключу (кстати, опубликованному на сайте IANA). Если делать всё добротно, то данные DS-записей для подписывания должны передаваться минуя DNS, по другим каналам, подразумевающим некоторую аутентификацию отправителя – иначе теряется большая часть смысла в развёртывании DNSSEC. Стандартный путь проходит через регистраторов доменов.

Итак, для получения работающей конфигурации пришлось dxdt.ru и nox.su предпочесть домен tooktook.org, так как зона .org корректно подписана и размещение DS-записей в ней поддерживается крупными регистраторами (я воспользовался GoDaddy).

Функционирование каждого домена обеспечивают серверы имён (NS). Для tooktook.org я взял пару серверов с BIND 9.7.3 (это известная реализация DNS-сервера), который полностью поддерживает DNSSEC. На сайте ISC есть подборка инструкций по настройке DNSSEC в BIND-е. Я не стану приводить подробных деталей, потому что это будет офтопик, на мой взгляд (если что, то пишите вопросы в комментарии). Сам процесс создания подписанной зоны DNS несложен, и сводится к генерации нескольких ключей (закрытых и открытых), с последующим удостоверением с их помощью записей в файле зоны. В пакете с BIND есть все утилиты: dnssec-keygen, dnssec-signzone и т.п. То есть, на входе у вас текстовый файл зоны без подписей, на выходе – текстовый файл зоны, но уже с дополнительными записями (RRSIG, DNSKEY), содержащими подписи и открытые ключи для их проверки.

После того, как зона подписана, генерируем DS-запись (записи), содержащую значение хеш-функции от открытой части ключа (KSK), с помощью которого подписан ключ (ZSK), удостоверяющий записи в зоне. (Пара ключей используется для удобства их ротации и оптимизации процедуры подписывания зоны. И, да, можно сгенерировать DS-запись до подписывания зоны.) В случае с доменом tooktook.org я без каких-то трудностей разместил DS-запись при помощи клиентского веб-интерфейса GoDaddy. На удивление, весь процесс – генерация подписанной зоны, размещение записей, – занял примерно 20 минут, включая ожидание обновления информации в DNS.

Теперь tooktook.org подписан (проверить можно с помощью веб-интерфейса от VeriSign). Зачем? Следующий шаг – проверка на практике технологии, дополняющей, с помощью DNSSEC, механизмы использования SSL-сертификатов в браузерах и уже поддерживаемой в Chrome. Нужно же посмотреть, что нас ждёт в ближайшем будущем.

Сегодня 11.11.11 – первый день для массового продления регистрации доменов .РФ. Ровно год назад зарегистрировали существенную часть кириллических имён. По итогам продления будет видно, насколько имена оказались востребованы. (Надо заметить, что если посмотреть в статистику DNS, то трафик на кириллических именах сейчас просто не сравним с трафиком в .RU – отличается на несколько порядков, не в пользу кириллицы, конечно.) Впрочем, освобождаться домены начнут в декабре: правилами предусмотрен 30-дневный срок “преимущественного продления”, в течение которого домен не удаляют из реестра. (Но особого энтузиазма в прогнозах нет.)

Как используется инфраструктура SSL-сертификатов в домене .ru? Я тут недавно попробовал посмотреть, в выходные. Для чего собрал сертификаты с узлов, на которые показывают домены .ru. Некоторые предварительные результаты – в этой заметке, но так как там довольно длинное описание с числами, то прячу его под “читать полностью”. Вообще, интересно будет делать регулярный мониторинг. Наверное, ежемесячно. И смотреть, что изменяется.

Итак, SSL-сертификаты и домен .RU.

Читать полностью

Не так давно я писал про удостоверение SSL-сертификатов с помощью DNSSEC. Оказывается, как мне подсказывают, подобная функциональность уже включена в рабочий Chrome 14, примерно пару недель назад. В общем, процесс движется быстро. Интересно, кто успеет запрыгнуть в вагон?

Кстати, часто думают, что для того, чтобы использовать открытую WiFi-сеть в качестве аналога анонимного прокси, человеку нужно обязательно присутствовать в зоне действия этой сети. Например, расположившись под окном незадачливого “домашнего пользователя” с ноутбуком. Но на практике ситуация иная.

Для специалиста нетрудно заполучить устройство, проксирующее запросы в WiFi из других сетей. Скажем, наиболее логичный вариант – “шлюз” между 3G сотового оператора и WiFi. Такой шлюз можно построить на базе едва ли не всякого современного смартфона. То есть, мобильный аппарат размещается (скрытно) в зоне приёма открытого WiFi, а уже к самому этому аппарату можно обращаться из любой точки Интернета. Цели использования понятны: скрыть следы.

Примерно месяц назад стало известно, что двое исследователей (Juliano Rizzo и Thai Duong) разработали метод использования уязвимости в протоколах TLS 1.0 для перехвата информации из зашифрованных сессий. Недавно обнародовали технические детали. Разработчики Firefox реагируют так: в самом браузере уязвимости нет, но уязвимы плагины Java, поэтому Java нужно отключить. Рассматривают возможность блокирования Java по умолчанию. Радикальная мера, да. Вот как развиваются события. Главное, чтобы реакция Mozilla на каждую “протокольную уязвимость” не превращалась в сверхреакцию.

Интересно, что при этом немало приложений для работы с защищёнными системами (банк-клиенты, доступ ко внутрикорпоративным ресурсам – см. решения Cisco, – и т.п.) используют именно Java, отказываться от них пользователи не станут. (Да, кстати, обнаруженный дефект TLS технически не связан с недавней шумной историей про SSL.)