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

В корневой зоне 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, к бизнесу по “управлению доверием” прямо подключаются регистраторы доменов.

Взломанный удостоверяющий центр DigiNotar – похоже, начинает процедуру банкротства. Вот вам первый пример нового регулирования. Отозвали корневой сертификат из браузера – беда: никому не нужны услуги такого УЦ. Не, понятно, конечно, что всё может быть не так просто и прямо. Может, это только повод, а “финансы там давно уже вывели” и подготовят теперь вторую такую же компанию. Но, тем не менее, скандал выходит масштабным. А левые сертификаты, тем временем, всё ещё ходят, потому что далеко не везде корень DigiNotar отозван.

Хотя, особенно доверять имеющейся инфраструктуре УЦ SSL и так нельзя. Посудите сами: какие у конкретного пользователя обычного браузера есть основания доверять кому-то из всего этого сонма неизвестных ему коммерческих компаний? (Ещё о доверии производителю браузера – можно как-то рассуждать, в этом случае. Но к набору УЦ в браузере это доверие имеет минимальное отношение.)

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

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

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

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

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

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