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

Как известно, перехват HTTPS проще реализовать при участии удостоверяющего центра, который, технически, может выпустить особый сертификат, позволяющий перехватывающему узлу выдать себя за легитимный сервер, с которым планировал соединиться пользователь. Эта особенность протокола ставит удостоверяющие центры в положение, когда их (вполне обосновано) постоянно подозревают в выпуске “перехватывающих сертификатов”. Или, как минимум, в содействии такому выпуску. После недавних “разоблачений АНБ” эта, чисто административная ситуация, сильно обострилась. Проблем добавляет и тот факт, что стандартные средства TLS/SSL, изначально разработанные для защиты коммерческих транзакций, выполняемых через Интернет, сейчас используются жителями разных стран с целью защиты личных сообщений и прочих важных данных.

Тут возможно техническое решение, которое ввело бы некий дополнительный распределённый нотариат, поддерживаемый сообществом и, поэтому, независимый как от удостоверяющих центров, так и от разработчиков браузеров. Я писал про инициативу Certificate Transparency, она как раз является одним из таких нотариатов. Так вот, интересно, что удостоверяющим центрам появление такого сервиса должно бы быть полезным. Этот сервис, если он будет развёрнут повсеместно, лишает выпуск “перехватывающих сертификатов” всякого смысла: встретив подобный сертификат, браузер всё равно будет выдавать предупреждение системы безопасности. И это должно снять подозрения с удостоверяющих центров.

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

Впрочем, нужно подождать, посмотреть, что выпустят производители браузеров.

В продолжение записки о том, что внутри W3C на полном серьёзе обсуждают внедрение механизмов DRM в стандарты HTML. Речь, в частности, идёт о некоем предложении под названием Encrypted Media Extensions (EME). Похоже, планируется использовать известную схему: в браузере должен быть некий программный интерфейс, позволяющий не только управлять исполнением кода снаружи, но и внедрять внешний код в браузер, прозрачно для пользователя.

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

В “Мозилле”, кстати, уже появился “баг-репорт”, требующий запрета реализации DRM в браузере. Посмотрим, как дело будет развиваться.

W3C продолжает сходить с ума. Во-первых, там никак не откажутся от введения в стандарты механизмов DRM. Во-вторых, дошли уже до того, что формируют под своим крылом рабочую группу, цель которой (буквально!) защитить стандартами исходные коды браузерных HTML5-приложений от просмотра пользователями браузера. Цитата из описания целей группы: “this group intends to find mechanisms of code protection for web apps, especially for packaged apps, making the source codes (e.g. HTML, CSS, JavaScript), as well as relevant resource files (image, audio and video, etc.) cannot be seen easily“. То есть, намереваются стандартизовать запрет на просмотр пользователем исходного кода веб-страницы (грубо говоря, нельзя будет использвать CTRL+U). Вот такие феерические задачи нынче ставит перед собой W3C.

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

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

Tor – один из самых популярных в Интернете методов “анонимизации”. Число пользователей (или клиентов) Tor за прошедший месяц выросло в четыре, примерно, раза, о чём свидетельствует статистика с сайта проекта:

Впрочем, в блоге Fox-IT пишут, что причина тут, возможно, не в возросшем интересе к “анонимизации”, а в ботнетах, которые стали активнее использовать Tor для связи между узлами и центрами управления.

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

Итак, получение трафика реализуется с помощью его перенаправления или копирования в сети NSA. Перенаправление реализует транзитный узел, который нужно правильно подобрать. Пользовательский интерфейс наверняка устроен следующим образом: оператор вводит требуемый IP-адрес, обозначающий либо пользователя, либо сервер; система находит в базе данных, хранящей сведения о топологии сети, подходящие точки присутствия NSA, через которые может проходить трафик для заданного IP, проверяет, что этот трафик там есть, обнаружив трафик – ставит его на прослушивание, включает перенаправление. Нужно различать два режима работы с трафиком: активный и пассивный. В пассивном случае трафик лишь копируется в анализирующий сегмент. В активном – перенаправляется, то есть, между двумя точками, устанавливающими соединение, появляется дополнительный узел. Кстати, активный режим, работающий на уровне IP, сейчас штатно используется интернет-провайдерами для фильтрации доступа к интернет-ресурсам. Так что это вполне стандартный инструмент.

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

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

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

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

Кстати, по этой же теме: “Вывод информации, снятой с подводных кабелей“.

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

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

Виртуальный хостинг RU-CENTER доступен на нескольких площадках (дата-центрах) – Москва, Амстердам, Новосибирск. Для сравнения площадок сделали вот такой сервис: hat.nic.ru – просмотр уровня доступности площадки в зависимости от региона. Для построения оценки собрана довольно приличная статистика: около 4 млн запросов (примерно 1 млн уникальных IP-адресов; это за месяц).

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

В общем, hat.nic.ru – полезный сервис, позволяющий понять, на какой площадке лучше разместить веб-сайт, в зависимости от географического распределения аудитории.

Интересно представить, как может работать гипотетическая система “тотального” прослушивания NSA защищённого интернет-трафика. Защищённый интернет-трафик, в подавляющем большинстве случаев, использует TLS/SSL, с теми или иными SSL-сертификатами. Самый известный пример такого использования – защищённая версия HTTP, HTTPS, его и возьмём в качестве примера. Другим источником сведений о гипотетической системе послужат скриншоты неких интерфейсов доступа и другие фрагменты презентаций, которые были опубликованы в СМИ. (Напомню, что я уже писал о перехвате HTTPS ранее.)

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

Начнём со второй задачи, с расшифровки или предотвращения шифрования данных, предположив, что трафик уже перехвачен.

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

Как получить серверный ключ? Если NSA внедряет закладки в программное и аппаратное обеспечение, то, вероятно, есть возможность вычислить секретный ключ за разумное время. Например, для самой популярной криптосистемы RSA достаточно знать разложение на простые множители модуля, используемого в данном секретном ключе. (Модуль – это, грубо говоря, число, задающее множество, в котором проводятся операции для даннной пары закрытый/открытый ключ.) Это не единственный способ, есть множество других. Закладка NSA с указанными свойствами приводит к уменьшению количества возможных ключей. В качестве наиболее вероятного рычага воздействия закладки принято называть генератор (псевдо)случайных чисел. Действительно, как бы хорошо не была реализована сама криптосистема, если практическое число возможных ключей, порождаемых генератором “неслучайных” чисел, не велико, то и от самой системы толка нет.

Тривиальный пример. Предположим, в NSA, воздействуя на производителей криптомодулей, на разработчиков программного обеспечения, добились того, что количество простых чисел, используемых в качестве одного из сомножителей в ключах RSA, которые генерируются “сертифицированными средствами”, не превышает 10^12 (триллион). Второе число может быть истино случайным, ведь тут важно не переборщить: чрезмерно малое разнообразие ключей будет быстро обнаружено наблюдателями (см. историю с ошибкой в Debian OpenSSL, которая, кстати, теперь уже и не кажется просто ошибкой). Зная структуру множества этих выбранных простых чисел, можно быстро вычислить секретный ключ простым перебором. Чуть более технично: пусть модуль ключа RSA представляет собой произведение двух простых чисел; если наш суперкомпьютер выполняет миллион пробных делений в секунду, то, исходя из 10^12 вариантов известных множителей, мы получим разложение для модуля не более чем через 278 часов; это означает, что факторизация будет обычно занимать чуть более недели. Заметьте, что серверные ключи традиционно существуют в неизменном виде годами.

Весьма занимательно, что в прошлом году было опубликовано исследование ключей TLS-серверов Интернета, в котором обнаружено заметное число разных ключей, имеющих общие простые множители.

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

Вычисленный ключ попадает в базу данных и становится доступен пользователям системы прослушивания HTTPS. Трафик можно начинать записывать сразу, не дожидаясь готовности ключа. Например, если взглянуть на те же веб-сервера Mail.ru, то они, как и подавляющее большинство других сервисов Интернета, не поддерживают прогрессивной секретности (forward secrecy) для HTTPS, это означает, что ранее записанный трафик можно расшифровать позднее, когда станет известен серверный ключ. (Подчеркну: я не вижу тут какой-то ошибки со стороны Mail.ru – они просто следуют сложившейся практике.)

Продолжение про перехват HTTPS – в следующей части, рассказывающей о перехвате трафика.

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

Очень интересно, что российский почтовый провайдер Mail.ru опять фигурирует в презентациях NSA (АНБ). Полюбуйтесь – здесь указан IP-адрес сервера (94.100.184.14) из сети Mail.ru:

(Примерно 2:08 в видео.)

Не вдаваясь в оценки связи с реальностью “скриншотов” интерфейса системы NSA из СМИ, отмечу, что трафик на серверы Mail.ru вполне мог перехватываться, при условии, что тот или иной транзитный маршрутизатор перенаправлял нужный поток в NSA (о чём упоминается на тех же слайдах).

Опять повторяется история с перехватом управления доменом известного ресурса, с последующей сменой серверов имён и перенаправлением всего трафика на сайт атакующих. Вчера такая штука произошла с доменом The New York Times. Причём, из-за кеширования DNS, перенаправление происходило долгое время после того, как правильную адресацию в домене восстановили. Понятно, что атака позволила перехватить и электронную почту, работающую в домене. А это, в свою очередь, первый шаг к перехвату аккаунтов в разных других сервисах, при помощи “напоминалок паролей”.

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