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

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

Как известно, многоязычные домены устраивают таким образом, что на клиентской стороне многоязычное имя преобразуется в допустимую к использованию в DNS “абракадабру” из ASCII-символов. Например, “бармалей.ru” кодируется в XN——80AABSUKF5A.RU. То есть, с формальной точки зрения, никакого расширения алфавита в собственно DNS не происходит, а предлагается лишь начать регистрировать “абракадабры” строго определённого вида.

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

С другой стороны, все эти мероприятия по набиванию “абракадабры” в командную строку – прямо противоречат исходным целям DNS, ради которых она создавалась. Ведь доменную систему имён придумали как раз для того, чтобы вместо численной “абракадабры” (IP-адресов) предложить пользователям-человекам удобные для запоминания, “мнемонические” адреса (компьютерам-то DNS вообще не нужна). Однако вряд ли XN——80AABSUKF5A – это удобная для запоминания строка. Так что админы оказываются вытеснены в такую область, в которой назначение DNS становится каким-то другим. Как бы даже и противоположным, ведь запомнить “XN——…” – может быть сложнее, чем IP-адрес. (Тут, конечно, ситуация выглядит ещё более забавной, если вспомнить, что админов планируют пересадить на IPv6, но это уже другая история.)

В чём причина трудностей админов? Причина простая: Интернет стал коммерческим инструментом, отсюда и новые приоритеты. В рамках “классической” DNS, скажем, вообще нет ни малейших оснований для появления новых доменов верхнего уровня общего назначения (не национальных) в дополнение к “изначальным”. Однако ж в коммерческом Интернете домены такие появляются многочисленными партиями (.NAME, .BIZ, .INFO и т.п.) – потому что они нужны маркетологам.

И, понятно, что админам никуда не деться. В своё время они, по сходным причинам, переучивались, скажем, на Windows.

Оказывается, в терминологии продуктов “Лаборатории Касперского” то, что “срок действия ключа истекает” – это угроза безопасности (прямо так и пишут). В общем, угрожают. Кошмар. (И немедленно перешёл на конкурирующий продукт.)

Как известно, новая версия программного продукта “Лаборатории Касперского” (KIS-2009) предлагает пользователю присоединиться к сети “Kaspersky Security Network”, формально для того, чтобы отправлять в лабораторию сведения о новых вирусах. Но, судя по всему, это такой первый (или второй?) шаг на пути “преобразования” компьютеров пользователей продуктов “Касперских” в узлы распределённой вычислительной сети.

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

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

Кстати, то, что некоторая CMS насчитывает N (N<10000) установок и при этом ни разу не была взломана – никак не гарантирует, что данная CMS сколь-нибудь защищена и безопасна; более того, такой показатель вообще не позволяет “определить безопасность” CMS.

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

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

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

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

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

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

(Фото к тексту отношения не имеет.)

Видимо, скоро придётся переезжать блогом с WordPress на другую CMS. Потому что новая версия 2.6 появляется уже раньше срока (торопятся, оказывается) и содержит какие-то излишние улучшения и украшения.

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

Между тем, шумиха про уязвимость DNS, якобы “массово исправленную”, это не более, чем очередная PR-акция в поддержку повсеместного введения DNSSEC. Именно так. С очень забавным пафосом про уязвимость пишут рунетовские интернет-СМИ. Например:

“Уязвимость […], которая могла бы затронуть значительную часть Интернета, исправлена общими усилиями специалистов по сетевой безопасности и крупных корпораций…” – это “Вебпланета“.

Что такое DNSSEC? Это такая технология, массового введения которой всё равно не избежать. Вот. Цель DNSSEC в том, чтобы привить небезопасной по самой своей природе системе DNS хоть какие-то “элементы безопасности”, соответствующие реалиям современного Интернета, в котором, к сожалению, всё меньше места для доверия (зато – всё больше места для криптографии). Подробнее – как-нибудь в другой раз.

Давненько мы не касались интернет-технологий. Нужно исправлять упущение. В этот раз – про “Большого брата” и рекламный таргетинг.

Известно, что во многих случаях рекламу лучше покупают у того “рекламного провайдера”, у которого она эффективнее. То есть чем больше товаров/услуг удалось продать в пересчёте на бюджет, тем лучше. Хотя понятно, есть, видимо, множество оговорок, о которых лучше спросить маркетологов. Особенно в свете того, что наша записка о другом.

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

“Яндекс.Директ” следит за посетителем на других сайтах, используя историю его поисковых запросов. Это делается через браузерные куки (небольшие файлы, которые веб-сервер может сохранить “в браузере” посетителя сайта). Объект компьютерной слежки на поиске “Яндекса” вводит запрос, – например, “крутые газонокосилки”, – сервер “Яндекса” фиксирует запрос в своей базе, связывает его с уникальным идентификатором и выдаёт соответствующую куку браузеру.

В дальнейшем, объявления “Яндекс.Директ”, соответствующие ключевым словам из запроса (скажем, “газонокосилки”), преследуют “объект”, уже покинувший поиск “Яндекса”, на других сайтах, участвующих в этой рекламной сети. Интересно, что так как объявления браузер загружает с серверов “Яндекса”, то куки будут работать, даже если они отключены для текущего сайта, но разрешены для “Яндекса”.

Есть, конечно же, и другие способы. Например, код рекламной сети может отслеживать ссылку, по которой пришёл на данный сайт посетитель, и регулировать выдачу объявлений в соответствии с “тематикой ссылки”. Продвинутая система уже использует запись истории “сёрфинга”, опознавая веб-читателя по кукам и IP-адресам. На основании истории возможен уже “поведенческий таргетинг“, понятно, в автоматическом режиме. Хороший провайдер контекстной рекламы дружит с распространёнными “счётчиками” (то есть с сервисами статистики, устанавливающими свои кнопки на сайтах, например – li.ru). Понятно, что чем больше сайтов охвачено системой учёта, тем более точная возможна слежка.

Но развитие чисто интернет-систем “рекламной слежки” уже подошло к своему пределу, многое съедено, места для развития всё меньше. Что дальше?

Что нужно для того, чтобы сделать идеального “Большого брата”?

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

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

Для чего куки, если провайдер и так видит сетевую активность пользователя? А вот для чего: предположим, что этот провайдер предоставляет доступ по Wi-Fi, в самых разных районах, самым разным, свободно перемещающимся по этим районам, пользователям. Раздача пользователям дополнительных идентификаторов, например, в тех самых куках – очень хорошо поможет различать пользователей в дальнейшем. Особенно тогда, когда пользователь подключится к другому интернет-провайдеру с того же самого компьютера. На этом шаге, кстати, играет решающую партию карманный интернет-ресурс, упомянутый выше в качестве дополнительного инструмента: используя этот ресурс, можно опросить куки и определить, к какому же провайдеру перешёл пользователь.

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

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

Кто первым построит подобную систему в Рунете? Ответ на этот вопрос вынесем за рамки заметки.

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

Так получилось, что я уже пару поясняющих записок написал о домене .РФ: про шумиху, производимую противниками, верящими мифам, и про фишинг в кириллическом домене первого уровня. Так вот, видимо, справедливости ради нужно написать и про технические проблемы с кириллическими доменами, которые, конечно, возникнут.

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

Зато реальные проблемы будут в различном системном программном обеспечении и в целом ряде плохо сконструированных веб-сервисов. Проблемы эти происходят из того, что во многих программах встроен собственный контроль валидности интернет-адресов. Валидность практически поголовно проверятся с помощью простой “фильтрации” вводимых символьных строк. Например, пользователь веб-сервиса вводит свой адрес e-mail, а сервис хочет проверить адрес на “минимальную валидность” (это весьма разумная практика). Для этого, скажем, есть регулярные выражения на Perl, позволяющие отсеивать заведомо неверные адреса. Подобные фильтры сплошь и рядом применяются непосредственно к пользовательскому вводу (подтверждения можно легко найти, исследовав, например, исходные коды каких-нибудь форумных движков или CMS).

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

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

Что делать?

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

Собственно, например в Google, через форму добавления сайтов уже можно отправлять многоязычные URL. А во вполне русскоязычный (вроде бы) “Яндекс”, как, впрочем, не сложно догадаться, – нельзя. Там, конечно же, равно такая ситуация, как и только что описанная:

Очевидно, у Касперских действительно уже есть какие-то хитрые криптологические ходы в запасе, чтобы раскрыть ключи шифрующего пользовательские файлы вируса Gpcode. Иначе публиковать приглашение к факторизации 1024-битного ключа RSA “всем миром” – это несколько странно.

А если есть ходы, то получается такой хороший PR (все кому не лень перепечатали ж пресс-релиз) и позже получается закрытый ключ (после применения “хитрых ходов”). Собственно, они же и сами честно пишут:

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

Понятно, что приступать к факторизации, имея на руках только 1024-битный ключ (если он хороший, конечно) – было бы поспешным решением со стороны специалистов.