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

“Яндекс” запустил открытый сервис DNS (открытые резолверы). Сервис похож на Google Public DNS. Однако у яндексового варианта есть дополнение – фильтрация адресов:

Яндекс.DNS – это бесплатный DNS-сервис, блокирующий опасные сайты и сайты для взрослых.

(http://dns.yandex.ru/)

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

При обработке запроса об адресе “заблокированного” ресурса приходит ответ, содержащий IP-адрес некоего принадлежащего “Яндексу” сервера перенаправлений, который отвечает по HTTP (это уже прямая подмена соединения!) редиректом на специальную страницу внутри yandex.ru. Эта страница устроена так, что охотно показывает сообщение о блокировании любого адреса, который передан в параметре URL-а. Например: http://yandex.ru/adult?url=yandex.ru – пишет, что “заблокирован” yandex.ru. Это, мягко говоря, технологически некрасиво. (Да, многие операторы связи сейчас делают подобное. Это известно.)

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

Естественно, блокировать нехороший контент нужно. Но для этого не требуется ломать DNS. Нужно использовать белые и чёрные списки, встроенные в браузер. И подходящий браузер у “Яндекса” есть.

Поделюсь, пожалуй, кратким описанием Интернета.

Интернет – это группа постапокалиптических технологий, не дождавшихся своего часа.

Можно добавить: пока не дождавшихся. Хотя, нельзя со всей уверенностью сказать, что современный Интернет может пережить всякий конец Цивилизации.

Нередко спрашивают, где посмотреть на примеры SSL-сертификатов, связанных с тем или иным инцидентом, отражающим очередной провал в работе удостоверяющих центров. Откроем браузер Firefox, я взял версию 19.0.2, найдём там в настройках раздел Advanced, воспользуемся вкладкой Encryption и кнопкой View Certificates, выбрав в открывшемся окне вкладку Servers (я сделал скриншот):

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

Ещё немного по теме прослушивания Skype. Из сообщений представителей самого Skype и отчётов аудиторов давно известно, что это ПО использует стандартные криптографические примитивы (AES, RSA и так далее), но местами делает это, на уровне протоколов, проприетарным образом. Да, понятно, что, например, AES, в качестве основы шифрования потока данных, – это хороший тон. Да, Skype использует P2P-сеть для транспорта трафика, а ключи, как заявлено, генерируются на клиенте. Всё это хорошо. В теории. Вопрос – можно ли организовать прослушивание?

Ответ есть. Сразу оговорюсь, он тоже чисто теоретический. Протоколы обмена ключами между сторонами, образующими то самое P2P-соединение, нередко базируются на присутствии третьей стороны, которой доверяют оба участника. Третья сторона удостоверяет данные участников обмена информацией, в том числе, сессионные ключи от AES. Это стандартное хорошее решение (но не единственно возможное, заметьте). Насколько я помню, Skype использует собственный удостоверяющий сервер, открытые ключи которого известны клиентскому ПО и позволяют проверять подлинность рекивзитов других пользователей при установлении соединения.

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

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

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

СМИ опять пишут про то, что “китайская версия” Skype содержит встроенные средства “цензурирования” и просмотра пользовательской активности. Преподносится как новость. На самом деле, этой теме уже несколько лет. Занимательно, что в работе 2011 года, которая сейчас (почему-то только сейчас) послужила поводом для шума, перехват обращений китайского клиента TOM-Skype производили с помощью подмены ответов DNS:

To decrypt this file, we redirected skypetools.tom.com DNS queries to our own HTTP server, allowing us to force TOM-Skype to load keyfiles of our choosing.

Очень верный, эффективный метод.

Вопрос – зачем о подобной прозрачности некоторых разновидностей Skype в СМИ вспомнили сейчас? Сначала отправили пилотные публикации, их уже перепечатывают, на голубом глазу, менее расторопные сайты. Может, это связано с популярной в Штатах темой “китайских кибервойн”? Есть, конечно, ещё более банальное объяснение – отдуваться за Skype теперь нужно Microsoft. (Так считается. Хотя, не ясно почему. Skype всегда был, мягко говоря, подозрительной программой.)

Как я писал ранее, в RU-CENTER проводится сбор статистики по веб-технологиям, используемым в Рунете (публикация по этой теме). Теперь у робота, опрашивающего сайты, есть официальная информационная страница: monoid.nic.ru.

Сделал простой сервис, позволяющий проверить из браузера, есть ли поддержка DNSSEC у DNS-резолвера, которым вы пользуетесь. Скорее всего, это резолвер интернет-провайдера. Сервис здесь: dnssec.dxdt.ru.

Там, на странице сервиса, описано, как он работает. Механизм очень простой, но, во-первых, требует, чтобы был включен Javascript, и, во-вторых, определяет положение вещей с точностью до настроек браузера, а не операционной системы. Тем не менее, штука, на мой взгляд, полезная.

Интересное наблюдение. Издание “Лента.ру” – lenta.ru – обновило дизайн, не так давно. Вместе с дизайном, конечно, обновилась вёрстка страниц. Некоторое время назад я отметил, что верстальщики новой “Ленты” используют элемент HTML5 time без понимания, что это такое за элемент, демонстрируя, тем самым, карго-культ HTML5. В тот раз time использовали для “обрамления” строки, содержащей время публикации новости или статьи, при этом формат использовали вот такой (значение я, для примера, взял произвольное): “12:31, 31 января 2013“. Соответствующий код (неверный!):

<time>12:31, 31 января 2013</time>

Поясню: спецификация требует указывать время для time в машиночитаемом формате, либо внутри самого элемента, либо в атрибуте datetime. (Обратите внимание на этот атрибут – он чуть позже сыграет ключевую роль в карго-культе.) Собственно, элемент time для автоматической обработки и придумали, поэтому машиночитаемый формат необходим. “12:31, 31 января 2013” – формат, понятно, неверный. Смысла в подобном использовании time нет.

Теперь в “Ленте” подкорректировали вёрстку. В time добавлен атрибут datetime. Замечательно. Казалось бы, так и надо. Дело в том, что использование атрибута datetime, содержащего машиночитаемое представление времени, позволяет указать внутри самого элемента что угодно, в том числе, и “кириллическую” строку с названием месяца. Казалось бы, исправили ситуацию. Но, внимание: разработчики “Ленты” предпочли в качестве значения этого атрибута установить ту же самую строку недопустимого формата, которая раньше стояла только внутри time. Например: datetime=”10:41, 12 февраля 2013″. Просто скопировали, видимо.

И вот мы получили очередной карго-культ HTML5, включающий сложный обряд из двух ходов. Почему подобное происходит именно в “Ленте”? Вопрос риторический.

Кстати, если у вас есть секретный ключ от подписей DNSSEC, для, скажем, зоны первого уровня, то быстро подменять адреса и перехватывать трафик в доменах второго уровня этой зоны, не нарушая безопасности ключей, можно так: генерируется “теневая” зона, сразу содержащая нужные “перехватывающие” записи. Эта зона подписывается по той же схеме, что и публичный экземпляр. Узлы, осуществляющие перехват и подмену DNS, имеют доступ к “теневой” зоне, откуда в нужный момент извлекают подписанные записи. Естественно, такая схема работает только при наличии соответствующей авторизации.

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

Многие знают, что у Google есть полезный DNS-сервис – открытый резолвер, воспользоваться которым может каждый, Google Publi. Буквально на днях, судя по ответам серверов, Google Public DNS стал проводить валидацию DNSSEC. То есть, подписанные домены теперь проверяются. Раньше такой функции не было.

Дальше немного технической части.

Убедиться в поддержке DNSSEC можно следующим образом (8.8.8.8 – один из адресов резолвера Google):

$ dig @8.8.8.8 -t A +dnssec dxdt.ru

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 -t A +dnssec dxdt.ru
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45823 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

– наблюдаем установленный бит AD в ответе (зона dxdt.ru – подписана, это факт).

$ dig @8.8.8.8 -t A +dnssec broken.nox.su

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 -t A +dnssec broken.nox.su
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52027

– наблюдаем SERVFAIL, это правильно, потому что broken.nox.su – специально сломана, чтобы можно было протестировать поддержку DNSSEC; если резолвер не проводит валидацию, то в ответе будет IP-адрес (для broken.nox.su это, обычно, 0.0.0.0).

Ещё пример, используем добротно сломанный dotsu.su:

$ dig @8.8.8.8 -t A +dnssec dotsu.su

– ответом должен быть SERVFAIL, и оно так и есть, по крайней мере, на моей стороне.

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

Этот шаг Google может неплохо помочь в продвижении DNSSEC, а заодно повысит популярность их DNS-резолверов.

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

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

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

Нетрудно придумать ещё пять-семь сценариев. Но неизвестными останутся две вещи: во-первых, какой из этих сценариев уже осуществляется, и, во-вторых, есть ли он вообще в списке.