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

Очень удобно, когда имя сети Wi-Fi (SSID) говорит само за себя, то есть, содержит прямое указание на “административную” принадлежность: avtosalon-gorod, bank-takoyto, cafe-apelsin. У удобства есть обратная сторона: всякие современные мобильные устройства, поддерживающие Wi-Fi, пытаясь найти знакомую точку доступа, передают в эфир имена сетей, к которым они раньше подключались.

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

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

Записка про 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. Нужно же посмотреть, что нас ждёт в ближайшем будущем.

Как используется инфраструктура 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.)

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

История с чередой “поломок” удостоверяющих центров, выдающих SSL-сертификаты, наводит на довольно логичный вывод: коммерческую систему “управления доверием” могут очень сильно перекроить. Потому что момент подходящий.

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

Страшилка: этот “кто угодно” может вмешаться в канал связи и выдать себя за владельца test.ru. Неожиданным образом, этот момент лежит в основе продаж SSL-сертификатов. Предлагается поступать так: пользователь выбирает некую доверенную организацию, которая проверяет, что предъявитель сертификата действительно представляет test.ru; теперь пользователь принимает только те сертификаты для test.ru, которые подписаны доверенной организацией. Вроде бы, все довольны.

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

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

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

И вот тут появляется DNS и DNSSEC. В DNS единый корень. Как раз доменное имя (читай – инфраструктура DNS) позволяет типичному пользователю установить “первый контакт” с неизвестным ему ранее сайтом. DNSSEC, понятно, также содержит единый корень и подписать “что попало” – не выйдет, так как доменные имена должны быть уникальны. С чисто технической точки зрения с помощью DNSSEC можно удостоверить не только адресную информацию, но и дополнительные сведения, например, указать, какие именно сертификаты – или, что конкретнее, криптографические ключи, – может использовать сайт под данным доменом. Заметьте, существующая иерархия УЦ здесь уже не нужна!

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

Так что шумиха раскручена не просто так. Наверняка готовятся очень интересные перемены.

Дополнение: да, понятно, что при условии изменения порядка и появления у DNSSEC новой роли, корректирующей судьбу SSL, к бизнесу по “управлению доверием” прямо подключаются регистраторы доменов.