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

На прошлой неделе масла в огонь обсуждения непростой ситуации с иерархией SSL-сертификатов в Интернете подлил бренд Trustwave, представители которого открыто признали, что их удостоверяющий центр выпустил корневые сертификаты (или, возможно, один сертификат – как утверждают) для использования в составе систем мониторинга трафика. То есть, при помощи ключей от такого сертификата можно перехватывать HTTPS-соединения и просматривать трафик так, что рядовой пользователь даже ничего не почувствует: нет никаких предупреждений браузера, не меняется домен, не перенаправляются запросы. Схема работает благодаря тому, что корень Trustwave встроен в браузеры.

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

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

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

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

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

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

Кстати, вот долгоиграющая тема – мимикрирующий под домен “Проверка.РФ” адрес http://проверка.рф⁄click.dxdt.ru/. Я завёл этот адрес в 2009 году, в демонстрационных целях. Надо сказать, что браузеры с тех пор сильно улучшились, данный “кривой” адрес отображают хорошо, в Punycode. А вот Google пока что не меняется. Как и раньше, на странице выдачи по запросу “Проверка.рф” домен отображается кириллицей, результат неотличим от адреса под настоящим кириллическим доменом верхнего уровня. Впрочем, про это я уже рассказывал полтора года назад, со скриншотом.

Домен .РФ продолжает уверенно терять вес. Новые правила удаления доменов сгладили процесс, но всё равно – ситуация уже хорошо видна на статистических графиках:

По этой же теме – пост о печальных прогнозах в блоге регистратора RU-CENTER.

Сообщают, что в браузере Chrome планируется отказаться от поддержки онлайн-проверки SSL-сертификатов на предмет отзыва. Соответствующие протоколы позволяют браузеру проверить, не отозван ли сертификат, который ему предъявляет тот или иной сайт при соединении по HTTPS. И такая проверка проводится непосредственно перед тем, как принять (или не принять) сертификат, с помощью запроса к специальному серверу.

Тут, между прочим, кроется известный канал сбора статистики по посетителям защищённых сайтов: если вы приобрели и установили себе SSL-сертификат, подразумевающий онлайн-проверку отзыва, то браузеры посетителей при заходе на сайт (по HTTPS, понятно) будут дёргать соответствующие сервера удостоверяющего центра, сообщая, таким образом, что да, вот мы посещаем такой-то ресурс. В результате можно построить портрет аудитории сайта.

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

Да, интересно наблюдать, как Chrome сперва вылез в браузеры-лидеры, а теперь начинает активно влиять на технологические традиции рынка.

Делегирован домен .СРБ – это ещё один “нелатинский” домен верхнего уровня. При этом, в отличие от .РФ, состоит из трёх букв, включая одну “специфическую” – Б. Домен, понятно, для Сербии. Пример адреса сайта: њњњ.срб. Развивается система имён. Ещё лет десять назад такой вариант развития мало кому мог бы показаться вероятным. Хотя, идеи о нелатинских именах тогда уже сформировались.

И, кстати, строго говоря, это не второй кириллический домен, а третий. Потому что первым был .ИСПЫТАНИЕ.

Потихоньку развиваю nox.su (это иллюстрация использования DNSSEC, которую я планирую показывать на семинарах по теме): дополнил описание, поменял ключи (теперь два ZSK, как положено), опубликовал файлы зон (исходный и с подписями). Как и раньше, все доступно на сайте.

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

Напомню предысторию: в декабре 2011 года могло произойти массовое удаление доменов .РФ, зарегистрированных в первые дни свободной регистрации (с 11.11.2010); однако удаление доменов было заморожено 8 декабря и возобновилось только 29 декабря. Удаление теперь проводится по новой процедуре, в рамках которой ограничено число имён, удаляемых ежесуточно.

Так, из доменов .РФ, скопившихся в очереди на удаление, за каждую итерацию (то есть, за одни сутки, по рабочим дням) удаляют 10000. То же самое и с доменами .RU, но мы сейчас следим за .РФ. В результате кириллическая зона сдувается, но не так быстро – масса доменов, регистрацию которых не продлевают, размазана по времени. Типичный отрицательный прирост – около 8 тыс. доменов в сутки. Но не забывайте, что удаление производится только по рабочим дням (да и то, были пропуски). В числах это выглядит примерно так (данные stat.nic.ru): 29 декабря, когда удаление возобновили, в зоне .РФ было 954013 имён, по состоянию на 17 января осталось 912707; итого: -41306 доменов. Для сравнения, в домене .RU за тот же период – напротив, прирост +7415 имён.

В общем, пока что кириллическая доменная зона теряет численность. Если бы ограничений на удаление не вводили, то спад был бы очень резким, сейчас он размыт, но всё равно хорошо заметен. Прогнозы относительно итогового числа доменов, на которое уменьшится зона .РФ, есть разные, они начинаются от оптимистичных 100000 имён. Процесс удаления сойдётся где-то весной, тогда и сравним показатели.

Так как домен nox.su успешно подписан (DNSSEC), то делаю под ним информационную страничку о том, как, собственно, эта DNSSEC для конкретного домена устроена. Пока что там очень краткое описание (но с картинкой уже!), детализацию постепенно увеличу. Получается пример внедрения, да.

Вооружённый смартфоном человек охотно считывает при помощи камеры встретившиеся в окружающем пространстве особые метки-коды. Одни из самых популярных – QR-коды. Технология позволяет отправить веб-браузер, встроенный в смартфон, на произвольный URL (да, нужно подтверждение от пользователя, но, как показывает практика, это не проблема).

Самая занятная особенность использования QR-кодов вместе с Интернетом – в идеальной “геолокационной” функции. Изображения, размещаемые в офлайне, могут содержать уникальные коды. Разместивший знает, где именно какой код он оставил. А использование встроенной в смартфон камеры для распознавания изображения практически гарантирует, что пользователь, только что обратившийся по данной ссылке к веб-серверу, находится рядом с картинкой. Наклейка на столике в кафе “Лютик”? Будьте уверены, что пользователь – за этим столиком. Очень точная система. Не использует GPS и тому подобных штук, которые могут быть пользователем отключены.

Да, конечно, можно придумать несколько исключений: сохранил картинку, вышел из кафе, спустился в метро – только тут прочитал код. Но это далеко от реальных привычек массового пользователя.

Получается, потребитель QR-кода ничего не знает о том, что стоит за кодом. Человек даже не в состоянии прочесть этот код самостоятельно, без использования электронного устройства (сравните с “текстовым” URL). А вот владелец сервера, на который приходит браузер смартфона (мобильного устройства), напротив, обладает как минимум следующей информацией: некий IP-адрес, связанный с устройством (определяет оператора, провайдера, дополнительный источник данных о местоположении); тип устройства; тип ПО на этом устройстве, сведения о браузере; ну и весьма точные данные о местоположении пользователя в данный момент. Удобно, полезно.

По традиции, о капчах. На форуме RU-CENTER мы довольно давно сделали особую геометрическую капчу, но, вроде бы, я про неё не писал раньше. Пример этой капчи:

Капча многослойная. Например, до сих пор приходят сообщения, что там ошибка в тексте описания. Но никаких ошибок нет, просто текст описания является неотъемлемой частью капчи. Основная особенность этой капчи в том, что она отсекает “биороботов”.

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

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

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