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

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

В заметке, посвящённой этому событию, Брюс Шнайер пишет:
“Imagine a government using this sort of attack against another government, coordinating a series of fake tweets from hundreds of politicians and other public figures the day before a major election, to affect the outcome”. (Представьте, что правительство использует атаку такого типа в отношении другого правительства, скоординировав серии поддельных “твитов” от лица сотен политиков или других публичных фигур за день до важных выборов, чтобы повлиять на их результат.)

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

Интересно, что, как пишут, аккаунт Президента США Трампа не был затронут атакой. Если это произошло потому, что, силами Секретной службы и АНБ, государственные аккаунты особой важности отдельно защищены, то получается, что определённое регулирование в Twitter уже внедрено. Конечно, подобное скрытое и как бы “неформальное” регулирование – оно, во многих случаях, гораздо удобнее.

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

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

Эволюция телефонного аппарата продолжается.

Microsoft сообщает, что планирует внедрить поддержку DNS-over-HTTPS и DNS-over-TLS в ОС Windows. На ресурсе D-Russia.ru – мой комментарий по этой теме.

Много сообщений о том, что Интернету 29 октября 2019 года исполнилось 50 лет. В качестве точки отсчёта приводят факт обмена сообщениями между двумя компьютерами, которые находились на большом удалении (600 км) – этот обмен, согласно записям, произвели 29 октября 1969 года (Charley Kline, UCLA и SRI). Это событие, впрочем, моментом возникновения Интернета – не является.

Дело в том, что Интернет – это стек протоколов TCP/IP. Именно внедрение этих протоколов и сделало уже существовавший набор каналов связи между узлами-компьютерами – Интернетом. TCP/IP внедрили в 1983 году. От этого момента, действительно, следует отсчитывать годы истории Интернета. Раньше – это были другие сети (в частности, одна из версий ARPANET).

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

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

Некоторое время назад в СМИ обсуждалось введение в Казахстане “обязательного TLS-сертификата”, который требовалось установить на клиентские устройства, что позволяло выполнять прозрачный перехват TLS-трафика. Эта история уже не новая: такая же схема обсуждалась в Казнете несколько лет назад.

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

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

В работе по ссылке – показано, что механизм наследования достаточно силён для того, чтобы покрыть практически всю популяцию, собрав ДНК лишь у небольшой части людей. И речь тут идёт о том, что публичные “анонимизированные” базы позволяют идентифицировать персон, ДНК которых в базе отсутствует, но нашлись родственники разной степени “отдалённости”. Цитата:

“Используя конкретную модель, мы можем предсказать, что база данных с записями о приблизительно 3 млн жителей США европейского происхождения (2% соответствующего взрослого населения), позволяет найти для 99% населения данной этнической принадлежности как минимум одного троюродного родственника, а для 65% – как минимум одного двоюродного”.

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

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

О чём идет речь? Действительно, существует схема маскировки имени сервиса, под названием Domain Fronting. Схема построена на архитектурной особенности HTTPS: данный протокол использует TLS в качестве транспорта, соответственно, появляются два уровня – TLS и HTTP. С каждым из этих уровней связано некоторое имя сервера (имя хоста). В TLS это имя передаётся в поле SNI (Server Name Indication), в открытом виде, то есть, в виде, доступном для просмотра системой DPI. На уровне HTTP есть ещё одно имя сервера, оно входит в состав адреса документа (URI), который запрашивает клиент. Этот адрес, а следовательно и имя, входящее в его состав, передаётся уже в зашифрованном виде, поэтому недоступен для DPI.

Пример: пусть клиент, являющийся браузером, использует веб-сервер под именем “example.com” и пытается с помощью HTTPS извлечь документ по адресу “https://example.com/document.html”. Тогда при установлении TLS-соединения, которое происходит до отправки HTTP-запроса, браузером в поле SNI (TLS) будет передано имя “example.com” (обратите внимание: без полного адреса документа, только имя узла, домен). После того, как TLS-соединение установлено, браузер отправит GET-запрос HTTP, указав, согласно спецификации протокола HTTP, адрес документа “/document.html” и имя узла (в специальном поле заголовка HTTP-запроса, под названием Host) “example.com”. Это имя совпадает с именем на уровне TLS, в поле SNI, но вообще имена могут различаться, так как находятся на разных уровнях абстракции. Приложение, работающее по HTTP, вообще обычно не видит не только имени в SNI, но и самого протокола TLS.

Domain Fronting строится на подмене имён SNI и HTTP. В SNI указывается имя одного сервера, но после того, как TLS-соединение установлено, HTTP запросы отправляются с указанием другого имени. Поясню в терминах примера из предыдущего абзаца: в TLS SNI указывается имя “example.com”, однако GET-запрос уже отправляется с указанием “test.ru” в качестве имени хоста. Теперь на уровне HTTP указано совсем другое имя, но так как TLS и HTTP используют разный контекст, сервис, где размещён исходный узел (адресуемый example.com в нашем примере), может выполнять и HTTP-запросы к test.ru. Это будет являться побочным эффектом реализации HTTPS на стороне сервиса.

Теперь предположим, что из некоторого сегмента Глобальной сети доступ к test.ru по каким-то причинам невозможен. Используя Domain Fronting можно замаскировать запросы к test.ru под HTTPS-сессию с узлом example.com: так как HTTP-запросы передаются в зашифрованном виде, анализирующая трафик сторона видит только имя example.com в поле SNI TLS. Конечно, могут заблокировать и доступ к example.com, в том числе, по IP-адресу, но тут в игру вступает административная часть: представьте, что вместо example.com используется google.com (или какой-то другой массовый сервис) – мало кто готов блокировать условный Google. Конечно, чтобы всё сработало, требуется поддержка описанной схемы со стороны сервиса, используемого как прикрытие. Именно на этом этапе и возникает сервис “Амазон” CloudFront, который позволяет (или позволял, см. ниже) использовать такую схему для ресурсов, которые размещаются за CloudFront. При этом “заехать” за чей-то домен можно без ведома того клиента CloudFront, который этот домен использует штатно, что, конечно, не самая привлекательная особенность сервиса.

Метод маскировки с использованием Domain Fronting известен много лет. Наличие такой особенности объясняется тем, что для массового сервиса удобнее жёстко разделить TLS и HTTP – одни логические узлы обрабатывают TLS-соединение (выполняют “терминирование TLS”), а другие – работают с HTTP, уже в открытом виде. Поводом для новостей про “запрет обхода блокировок” как раз послужило то, что “Амазон” недавно обновил платформу CloudFront, исправив обработку контекстов и, тем самым, удалив возможность использования Domain Fronting. Думаю, понятно, что к “обходу блокировок” это если и имеет какое-то отношение, то весьма и весьма косвенное, и только со стороны тех нестандартных клиентов, которые данную особенность использовали. К ним, например, относится мессенджер Signal, который, впрочем, уже получил предупреждение о нарушении правил использования сервиса от Amazon.

Пишут, что шифры, предложенные АНБ, очередной раз не утвердили в качестве стандартов ISO (для “Интернета вещей”). Как следует из неофициальных публикаций, мотивируют решение против шифров АНБ тем, что агентство могло внести в них бэкдоры. Такая мотивировка сейчас популярна и привлекательна для СМИ, но каких-то внятных описаний бэкдоров, конечно, не предлагается. Шифры Speck и Simon – относятся к классу “лёгких” шифров, предназначенных для устройств, сильно ограниченных в вычислительных возможностях. Обычно, это микроконтроллеры, используемые для управления разным оборудованием, в том числе, бытовым. Я довольно подробно писал про Speck в прошлом году, рассматривая его реализацию для микроконтроллера AVR (точнее, для Arduino), в той записке есть схема шифра и соответствующий исходный код.

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

Cloudflare официально запустили сервис DNS-резолвинга 1.1.1.1 (это IP-адрес, второй: 1.0.0.1). Резолвер работал под этим адресом уже некоторое время, но Cloudflare широко заявили о нём только первого апреля (такая вот шутка). Особенности сервиса: заявлена поддержка и DNS-over-TLS, и даже DNS-over-HTTPS (есть и такой новый протокол). По адресу 1.1.1.1 – доступен веб-сайт. При этом 1.1.1.1 в глобальной Сети нередко фильтруется или используется нерадивыми сетевыми администраторами в качестве “локального” IP-адреса, для внутренних тестов (не все готовы поверить, что это “обычный адрес”). Соответственно, сервис Cloudflare может быть недоступен из некоторых сетей. А вот адрес 1.0.0.1 – может трактоваться как синоним 1.1 (да, в короткой записи, две единицы), что позволяет прямо так и обращаться к узлу: $ ping 1.1

(В контексте DNS-over-TLS, напомню, что пару лет назад “Яндекс” занялся встраиванием в свой браузер другой технологии обеспечения безопасности DNS – DNSCrypt, но, похоже, DNSCrypt оказался неверным выбором.)