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

Boston Dynamics тем временем сконструировали скоростную версию четвероногого робота. Пишут, что бегает со скоростью около 16 миль в час. То есть, человек убежать не сможет. По ссылке под картинкой ниже – видео испытаний. В условиях городских боевых действий для подобной платформы можно придумать немало вариантов эффективного применения.

(Видео.)

Они все громко жужжат генерирующим моторчиком. Видимо, это такая фирменная черта у Boston Dynamics.

(Найдено здесь.)

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

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

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

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

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

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

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

Кстати, сегодня 56 лет с момента успешного запуска СССР первого искусственного спутника Земли. Занятно развивается история: вот, в этом году сайт NASA 4 октября закрыт, так как Штаты с бюджетом не разобрались.

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 для связи между узлами и центрами управления.

Как и следовало ожидать, уже пишут, что сканер отпечатка пальца TouchID в новом аппарате iPhone удалось обмануть специалистам из ССС. В качестве исходника для имитатора использовали отпечаток пальца, снятый с самого аппарата и воспроизведённый при помощи лазерного принтера, плёнки и клея. Разумный комментарий Frank Rieger в тексте:

“We hope that this finally puts to rest the illusions people have about fingerprint biometrics. It is plain stupid to use something that you can´t change and that you leave everywhere every day as a security token”.

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

Можно, конечно, поспорить с тем, что биометрия, как утверждается в тексте по ссылке, это только “инструмент угнетения и контроля”, но использовать любой биометрический показатель в качестве ключа авторизации, без проверки уполномоченным человеком того, что перед вами стоит в добром здравии носитель этого показателя – действительно, неправильно. Уровень безопасности такая система точно не повышает, а часто – снижает, создавая новые риски.

Продолжение рассказа о гипотетическом устройстве системы перехвата защищённого интернет-трафика. В первой части рассматривается расшифровка 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 – полезный сервис, позволяющий понять, на какой площадке лучше разместить веб-сайт, в зависимости от географического распределения аудитории.