dxdt.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 оказался неверным выбором.)

Пишут, Израиль официально подтвердил, что в 2007 году нанёс удар по “ядерному объекту” на территории Сирии. Речь про удар 6 сентября 2007 года, когда разрушили большое защищённое строение. С этим событием связана первая волна сообщений о сверхсовременных средствах РЭБ, которые использовали израильские ВВС для противодействия силам ПВО: обсуждалось, что эти комплексы РЭБ не просто позволяют ставить активные помехи, но даже “перехватывать управление” комплексом. Правда, подразумевались сильно устаревшие советские комплексы. Я, кстати, писал на сходную тему, но позже, в 2010 году: Сигнатуры, ПВО и утечки информации по побочным каналам.

Ещё немного о навигации: из NASA сообщают, что успешно на практике использовали рентгеновские пульсары для определения положения аппарата в космическом пространстве. В качестве приёмника сигналов послужила рентгеновская обсерватория NICER, установленная на борту Международной космической станции, а сам эксперимент называется SEXTANT (Station Explorer for X-ray Timing and Navigation Technology).

Логика работы данного прототипа навигационной системы такая же, как описана в научной фантастике: периодические сигналы пульсаров обладают высокой стабильностью, соответственно, если их правильно подобрать, то можно вычислять положение приёмника. Что и продемонстрировали для МКС – отклонение (радиус) получилось лучше 10 миль, для космической навигации вполне достаточно (обещают улучшить).

А, так сказать, с литературной точки зрения, самое занятное – это если выяснилось бы, что пульсары действительно являются маяками, созданными некоторой древней цивилизацией, а сейчас земляне научились использовать их в своих навигационных целях.

В марте прошлого года я писал про направление атак, связанное с датчиками систем управления техпроцессами:

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

Эта тема, действительно, быстро развивается. Например, на Black Hat заявлен доклад как раз про устройства мониторинга уровня радиации, где речь должна идти и о беспроводных датчиках.