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

В продолжение темы про привязку авторизации к адресам e-mail. Как должна работать правильная напоминалка пароля от того или иного интернет-сервиса по e-mail?

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

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

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

А в дополнение к одноразовым ссылкам нужна капча в самом интерфейсе смены пароля.

На фоне озвучиваемых в СМИ планов по созданию новых государственных сервисов в национальном кириллическом домене интересно взглянуть на адресацию в Интернете с точки зрения “главных рубильников”.

Понятно, что всякий интернет-сервис намертво привязан к двум фундаментальным штукам: DNS (то есть, имена доменов) и IP (то есть, сами адреса, по которым доставляются пакеты данных). В этом кроется принципиальное отличие интернет-среды от, скажем, радиоэфира.

Радиоэфир общий по своей физической сути. Есть международные соглашения, регулирующие использование спектра частот. Но, по большому счёту, если вдруг очень сильно потребуется организовать вещание на той или иной частоте, то ни у одной международной (или просто коммерческой) организации не найдётся средств, чтобы технически вещание полностью заблокировать. Да, можно ставить помеху, блокируя приём передач в некотором кусочке пространства. Можно, в общем, вести РЭБ. Но просто взять, нажать кнопку, и отключить доступ к частоте для всех слушателей и для вещателя – такого, очевидно, нельзя сделать.

Совсем другое дело – системы интернет-адресации. Здесь есть главные рубильники, и главные кнопки, которые позволяют очень быстро отключить частоту. Самый простой пример – удаление домена из файла зоны. Удалить можно не только домен второго уровня, но и домен первого уровня. В результате все сайты из него станут недоступны. Так как опрос DNS всегда начинается с корневых серверов, то внесение изменений в корневую зону позволяет не только отключить любой домен первого уровня, но и, например, перенаправить трафик внутри этого домена на другие адреса. Конечно, требуется административный доступ к корневой зоне DNS.

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

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

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

Забрав управление доменом описанном незаметном режиме, новый администратор может переадресовать только какие-то ключевые сайты, оставив основную часть адресных настроек без изменений. Этот способ особенно хорош в том случае, если новый администратор не желает, чтобы под удар попали лояльные к нему интернет-сервисы: ведь понятно, что если “снести” домен полностью, то недоступными окажутся все ресурсы сразу; копирование установленной адресации – сильно смягчает ситуацию для рядовых пользователей. (Да, старые администраторы не смогут менять настройки доменов и т.п., и т.д. но это не так страшно.)

Заметьте, что изменение DNS коснётся и электронной почты в домене. Она начнёт ходить “не туда”.

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

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

(А при этом IP-адреса корневых серверов зашиты в системном программном обеспечении. Изменить их можно, но только в ручном режиме, при условии, тысячи системных администраторов будут действовать согласованно.)

Да, конечно, всё это теоретические сценарии. Но интересные. Так что, думаю, в следующих записках разбор темы можно продолжить. Тем более, что актуальность Интернета у нас растёт семимильными шагами.

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

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

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

Если нет “двухфакторной” авторизации при смене пароля через напоминалку, то всё совсем просто. И обычно никакой двухфакторной авторизации как раз нет. Например, CMS-ки в ответ на запрос “забыл пароль” традиционно высылают одноразовый ключ, позволяющий залогиниться в админку (так делает Drupal и другие).

Занимательности добавляет тот факт, что “брошенные” адреса периодически становятся доступными для новой “регистрации” совсем другими пользователями. И это вовсе не исключительная проблема бесплатных почтовиков (пишут, что проблемные домены имели в контактах адреса @mail.ru, @bk.ru и т.п.). Да, с освободившимися аккаунтами бесплатной почты – всё понятно. Эти адреса вне конкуренции: освобождаются чаще, захватить проще. Однако есть же и другие способы.

Во-первых, освободиться может домен, на котором имелись контактные адреса. Зарегистрировав такой домен вновь, можно настроить MX-записи и – вся почта домена ваша. Во-вторых, перехватив домены через регистрацию почтового адреса на бесплатной почте, можно проделать с MX-ами то же самое, опять получив всю почту доменов. Понятно, что и взлом NS-ов также позволит переправить почту.

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

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

Так, адрес из примера графически имитирует домен второго уровня проверка.рф, используя для имитации символ деления из специальной таблицы unicode. Получается строка вот такого вида: http://проверка.рф⁄click.dxdt.ru/, где третья слева косая черта – это вовсе не “слеш”, как можно подумать, а сам домен находится в зоне .dxdt.ru. (которой управляю я), а не в .рф. Когда та заметка публиковалась, домен РФ ещё не работал (кириллическая ссылка на dxdt.ru – работала, конечно; чем впечатляла специалистов: “а как это так?” – спрашивали они). Сейчас зона .рф доступна. И поисковики индексируют сайты в ней.

Сейчас в google.ru по запросу “проверка.рф” первой выдаётся как раз ссылка на тестовую страничку http://проверка.рф⁄click.dxdt.ru/. При этом в тизере адрес записан именно в кириллическом виде, а не в нотации Punycode, с префиксом xn--, как должно бы было быть при смешении таблиц unicode в адресе. Что и требовалось доказать. Вот скриншот:

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

Как это исправить? Понятно, что Google должен смешанные адреса в тизерах показывать в Punycode – то есть, вот так: http://xn--80adjurfhd.xn--click-uye2a8548c.dxdt.ru/

В конце мая Google, наконец-то, реализовал доступность поиска по HTTPS – https://www.google.com/. Правда, пока не все поисковые направления работают по защищённому протоколу, например, не поддерживает HTTPS поиск по изображениям. Да и вообще всё в статусе беты. Тем не менее, это важный шаг.

Так, у Google нашлось достаточно вычислительных мощностей, чтобы перевести на HTTPS один из самых своих массовых сервисов: нужно учитывать, что вычислительные затраты на работу по шифрованному каналу заметно больше, если сравнивать с простым HTTP. При работе с многими миллионами запросов – проблема с дополнительной нагрузкой встаёт в полный рост.

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

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

В ближайшие годы на HTTPS перейдёт ещё больше сайтов. Вряд ли, конечно, защищённая версия быстро полностью вытеснит открытый протокол – ведь используют же до сих пор FTP. Но доля трафика HTTPS сильно вырастет. Собственно, уже и только трафик Google – заметная прибавка.

При этом криптография активно внедряется и на уровне DNS – это DNSSEC, – и на уровне IP (здесь планируется сертификация маршрутов и автономных систем, с подписыванием ЭЦП анонсов BGP – об этом, наверное, нужно отдельную записку написать). Новый Интернет должен сформироваться уже лет через пять. Помимо перехода на HTTPS, важным моментом будет проталкивание поддержки DNSSEC на клиентские машины.

Собственно, домен .РФ делегировали уже сегодня. Не дожидаясь завтрашнего форума. То есть, завтра можно будет показать работающие сайты в новой зоне. Вот вам такой сайт: президент.рф. Другой адрес: кц.рф (и это не про известный фильм “Кин-дза-дза”, как можно подумать).

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

Напомню, что уже делегированы арабские IDN верхнего уровня, поэтому РФ не стал первым “нелатинским” доменом, зато, вероятно, станет первым кириллическим (как, впрочем, и ожидалось ранее). При этом Совет ICANN одобрил сразу “пачку” новых доменов, и в составе той пачки как раз был РФ, вместе с доменами Саудовской Аравии, Египта и Эмиратов. В общем, ждём новостей.

Собственно, после развёртывания DNSSEC (пока в испытательном режиме), появились первые многоязычные домены (IDN) верхнего уровня в корневой зоне. Домена РФ среди них нет. Первые IDN верхнего уровня – на арабском. Это домены Египта, Саудовской Аравии и Арабских Эмиратов. Пресс-релиз ICANN – здесь.

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

Объяснение разработчиков процедуры – такое: использование кривого ключа гарантирует, что особенно продвинутые участники глобальной Сети не перейдут на полную поддержку DNSSEC раньше времени. Действительно, с “кривым” ключом использовать DNSSEC на практике смысла нет, поэтому клиенты не станут массово и полностью внедрять поддержку новой технологии, так как они не смогут в таком случае работать с DNS. А вот если бы корневую зону подписывали сразу проверяемым образом, то откат оказался бы очень проблемным делом: те, кто перешли на DNSSEC уже не смогли бы работать с Сетью, если бы поддержку DNSSEC отключили.

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

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

(Про то, что теоретически такой вариант возможен для РФ – совершенно неожиданно упомянули представители Координационного центра на доменной секции в рамках РИФа. А вариант этот, мягко говоря, самый плохой из возможных.)

Например, не так давно “Гарант-Парк-Телеком” проделал фокус с независимым “открытием” домена РФ, создав на своих серверах домен “гарант-парк-телеком.рф” и предложив желающим изменить настройки серверов DNS так, чтобы этот домен заработал. Действия ввели в заблуждение многих несведущих в технических аспектах журналистов, поспешивших язвительно написать, что “на практике сайт гарант-парк-телеком.рф не открывается ни в одном браузере”, хотя он и не должен был открываться, так как Гарант-Парк-Телеком нарушил принципы построения глобального Интернета.

Преодоление этих самых принципов происходит приблизительно по следующей схеме рассуждений: а что нам эти RFC и IETF? мы сами с усами! Действительно, международной законодательной основы для функционирования Интернета – нет, а есть лишь некие соглашения и рекомендации (RFC), которым большинство участников обмена данными следуют. На определённом этапе развития ожидаемо появляются группы, которые считают, что “нам эти RFC – не указ!” и “мы сами знаем, как лучше, у нас есть свои инженеры и сети!”. И вот на следующем шаге строят собственные альтернативные корни DNS (они, кстати, есть уже развернутые, если кому интересно) и вообще сегменты как бы глобального Интернета, помещающие пользователя в “иную сетевую реальность”. (Примеры тут известны самого разного уровня, начиная от домовых сетей, в которых “понравившиеся домены” настраивали так, что они показывали совсем не на те ресурсы, на которые должны бы по задумке “глобально признанного администратора”. Обмануть ведь пользователя не сложно, можно так сделать, что он, набирая yandex.ru, будет попадать на локальный ресурс администратора сети).

Между прочим, практически то же самое можно проделать и с IP-адресами, если кто из подготовленных пользователей сомневается: просто, перенастройка таблиц маршрутизации и работы с BGP – несколько более сложное дело. Но проблема решаемая: работает же ведь технология anycast для IP-адресов распределённых сервисов.

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

Что интересно: ICANN появилась как раз для того, чтобы эффективно победить возникавшие десять лет назад альтернативные сегменты адресного пространства Интернета. Сейчас именно ICANN при прямом и активном участии Минторга США вводит новые эффективные инструменты противодействия провайдерам, которые “себе на уме” – это DNSSEC и новые политики сертифицирования распределения блоков IP-адресов. И в DNSSEC, и в распределении IP уже в самые ближайшие годы появятся криптографические механизмы, которые перекроют все простые ходы по подделке ответов DNS и перехвату адресов. При этом, в случае с DNSSEC, механизмы проверки будут проталкивать прямо на клиентскую машину, силами производителей операционных систем (выпустит, скажем, MS очередной апдейт – и вот, готово).

Вот.

P.S. Спасибо всем, кто таки пришёл на нашу секцию на РИФе. Данная заметка как раз написана по результатам обсуждения и ответов на вопросы в ходе секции.