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

Сегодня 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.)

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

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

Интересно, что так как современный Интернет делают для пользователей, то основные проводники пользовательского трафика (производители браузеров, поисковые машины, производители распространённых ОС) имеют полное право надавить на удостоверяющие центры (УЦ), выпускающие сертификаты SSL, в плане внутренних проверок. Более того, например, могут сговориться, и ввести какую-нибудь сертификацию для самих этих удостоверяющих центров. Потому что даже без поддержки лишь одним распространённым браузером, продавать услуги по выпуску SSL станет проблематично. (Собственно, Mozilla уже выступила с предложением о проверке УЦ.)

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

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

Ну и вот движение началось, уже в прессе широкого назначения пишут про “сценарии Египта и Туниса” в “Твитере” и Facebook:

“…единственным верным выходом является создание некой системы социального мониторинга, когда о каких-то подозрительных действиях сообщают сами пользователи”.

А это как раз и есть отличный фундамент для применения технологий второго порядка. То что нужно. Процитирую весеннюю записку:

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

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

(Кстати, пока вы не держите в руках исходные нити – всегда на шаг отстаёте, если играть только в одном “информационном поле”.)

На Сryptome выложен некий отчёт Fox-IT об аудите инфраструктуры DigiNotar, по следам взлома. Речь об августовском взломе удостоверяющего центра, когда были выпущены фиктивные SSL-сертификаты для *.google.com и других интересных ресурсов. Никаких технических подробностей в отчёте нет, но занятные моменты присутствуют.

Например, как пишут аудиторы про сети DigiNotar, критически важные сервера там были физически изолированы, но при этом доступны из локальной сети (видимо, имеется в виду некая общая корпоративная сеть, там не совсем понятно из текста) и объединены в единственный домен Windows (да, там использовали Windows, такое решение вполне возможно). Поломавший их специалист как раз и получил права администратора домена и, соответственно, за один раз обрёл доступ сразу ко всем нужным серверам. Удобно. При этом пароль от администраторской учётной записи был, что называется, угадываемым, а общего центрального логирования сетевой активности – не велось. (Вот так. Как обычно – искажённая модель угроз у админов корпоративной ЛВС привела к плачевным результатам.)

Ещё интересна хронология событий в случае с сертификатом *.google.com: 4 августа отмечают поток запросов на проверку отзыва этого сертификата (существует специальный протокол проверки, по которому работают современные браузеры), и только 29 августа сертификат реально отозвали. То есть, длительное время фиктивный сертификат мог работать без проблем.

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

Как интересно: оказывается, DigiNotar (удостоверяющий центр, чья система удостоверения была взломана) не уведомил Mozilla Foundation об инциденте, даже несмотря на то, что в рамках атаки на УЦ были выпущены фиктивные сертификаты для домена addons.mozilla.org. Вот такой вот уровень внедрения PKI и систем электронной подписи сейчас. Занятно, что, как пишут, тот же УЦ работает с правительством Голландии по какой-то там местной программе удостоверяющих центров. Это к вопросу об электронном правительстве.

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