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

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

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

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

Что касается STARTTLS. Для доставки электронной почты между почтовыми серверами в Интернете повсеместно используется протокол SMTP. SMTP – это “текстовый протокол”, то есть, его работа основана на командах, отправляемых в виде человекопонятного текста (ну, с точностью до числовых кодов состояний, которые, впрочем, тут тоже записываются ASCII-текстом) через любой подходящий транспорт. Многие достаточно древние протоколы в Интернете – текстовые. Потому что текстовые протоколы – это очень удобно и понятно. Там, где применимо. Сейчас, постепенно, этот подход возвращается (примеры: текстовые, REST-подобные API с JSON и др.), но, конечно, не везде.

Вернёмся к SMTP. Классические SMTP-сессии проходят в открытом виде, это означает, что содержание письма, доставленного электронной почтой, будет нетрудно просмотреть на любом промежуточном узле, которых легко могут быть десятки. (Обратите внимание, что дополнительные методы зашифрования содержания письма – PGP, S/MIME и т.д. – они относятся к другому уровню, не к SMTP.) Чтобы иметь возможность дополнительно защитить содержание писем в процессе доставки и используется STARTTLS: этот механизм позволяет SMTP-клиенту и SMTP-серверу перейти на защищённый канал “точка-точка” (см. пояснение ниже) после того, как они уже начали сессию в открытом варианте.

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

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

Поскольку сам SMTP полностью открыт, его не так уж трудно проксировать с изменениями, даже подменяя IP-адреса узлов. Серверное сообщение о поддержке STARTTLS можно просто вырезать из соответствующего ответа – если клиент допускает доставку без TLS, то он уже не будет пытаться установить TLS-соединение, а перейдёт к доставке в открытом виде. Это давно известная особенность, указанная в RFC.

В практике SMTP, при доставке писем между почтовыми серверами, принято не особенно строго подходить к обработке параметров TLS. Причина в том, что иначе почта перестанет ходить совсем. Поэтому TLS тут является примером того, что называется “приспособительным” (или “ситуативным”) подходом в использовании криптографии для защиты от прослушивания: “если удалось, то будем зашифровывать, а если нет – тогда ладно”. (В английском варианте – “opportunistic encryption”; однако переводить тут opportunistic на русский как “оппортунистическое” – не верно: соответствующие коннотации слишком сильно отличаются; это даже хуже, чем Чарльз, превращающийся в Карла.) Для защищённой работы SMTP есть и вариант использовать TLS-соединение сразу, до начала SMTP-сессии (SMTPS и др.), однако этот подход уже не имеет отношения к STARTTLS.

IDN – это “многоязычные доменные имена” (Internationalized Domain Names), подразумевающие преобразование кодировок на стороне клиента: Unicode кодируется при помощи Punycode, поскольку в DNS, пока что, Unicode не используется (полезная технология, вообще говоря, полезна лишь там, где действительно нужна и может быть внедрена, но это история для другой записки). Весьма неудобный дополнительный слой, который образуется из-за обработки IDN, постоянно приводит к проблемам. Самая “заковыристая”, а поэтому постоянно вылезающая тут и там, проблема – нормализация unicode-записи. Собственно, не так давно мне пришлось исправлять эту проблему в одном из сервисов, работающих с доменными именами. Но если сейчас посмотреть и потестировать те или иные профильные веб-интерфейсы, преобразующие IDN, то, думаю, данная экзотическая проблема проявится у многих (это особенно близко регистраторам доменных имён). Кстати, если этот текст читают разработчики подобных инструментов, то потестируйте имеющиеся реализации. Строки для тестирования я привожу ниже, вместе с описанием логики проблемы (впрочем, она уже упоминалась в прошлогодней записке про шумерские цифры, которую вряд ли много кто прочитал).

Итак, Unicode устроен весьма продвинутым способом. Настолько продвинутым, что там есть поддержка дорисовывания различных дополнительных значков (диакритических, например) к символам. То есть, имеются “закорючки” со “знакоместом”, на которое знакоместо ставится связанный символ. Это весьма полезно во многих системах письма. Однако некоторые буквы некоторых алфавитов имеют и “основное” представление в качестве отдельного кода, уже включающее в себя “закорючку”. Пример – русская буква “й”. Графически, это буква “и”, но с “чёрточкой” (называется “бреве” или “кратка”). Unicode позволяет закодировать “чёрточку” разными способами, как минимум, двумя – вместе с буквой и отдельно.

Посмотрите на две строки: “биткойн.рф” (1) и “биткойн.рф” (2) – они должны выглядеть одинаково. Эта одинаковость обманчива, потому что в первом случае “й” записано как U+0438 + U+0306 – буква “и” + “знак бреве”, два значения; а во втором случае – это просто буква “й” (U+0439, одно значение), где, так сказать, всё включено.

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

Возвращаемся к IDN. Эта технология требует преобразования кодов Unicode к DNS-записи, алфавит которой допускает (без учёта регистра) для подстрок имён хостов символы [a-z] (от “a” до “z”), [0-9] и “минус” “-” (точки тут не считаем). Для кодирования этими ASCII-символами байтовых значений Unicode используется алгоритм, называемый Punycode. Принцип тут аналогичен тому, как работает, например, Base32 (или “кодирование в рунах”), детали отличаются, но нам это здесь не так важно. Важно, что Punycode ничего не знает про особенности Unicode и просто отображает в подмножество ASCII значения unicode-байтов (и обратно), то есть, разные кодовые записи одной буквы отобразятся в разные punycode-последовательности. Что не так трудно продемонстрировать на нашем примере: “биткойн” == “qsa11dvaajue4a”, а “биткойн” == “90aoddqe0a” (выглядит занятно, да).

Однако с точки зрения DNS “qsa11dvaajue4a” и “90aoddqe0a” – разные значения, поэтому имена, их содержащие, тоже будут разными. Разный способ записи одного и того же графического представления для целей DNS не подходит – в реестрах имён, на серверах имён, первоочередное значение имеет ASCII-представление. Поэтому и используется процесс, называемый нормализацией, который описывает соглашение о том, как разные “чёрточки” так приклеить к буквам, чтобы привести всё к одной последовательности кодов, а уже её использовать, например, в DNS. Естественно, unicode-нормализация важна не только в DNS, но подробное описание принципов остаётся за рамками этой записки – его можно найти в соответствующем документе. Отмечу, что современные библиотеки для работы с IDN, обычно, позволяют прозрачно использовать нормализацию, нужно только не забыть её правильно включить при вызове функций преобразования. И, вообще говоря, алгоритмов нормализации – несколько, что делает ситуацию интереснее. А полагать, что столкнуться с подобным на практике невозможно, будет ошибкой – копирование символов иностранных письменностей в составе имён, которые не удалось ввести с клавиатуры, вполне себе встречается.

SPF (Sender Policy Framework) в Интернете позволяет администратору домена через DNS определить перечень адресов узлов, которые могут доставлять email-сообщения с адресами в данном домене. SPF публикуется в TXT-записях. Распространено мнение, что SPF – чрезвычайно простой инструмент, “всего лишь список IP-адресов”, который легко проверить, не получив фактического письма от почтового сервера. Конечно, если рассматривать практику массового применения SPF, то, действительно, так как большинство администраторов используют SPF в самом простом варианте записи, может показаться, что никаких дополнительных уровней логики там и нет. Это, однако, не так: спецификация достаточно сложная, определяет “макросы”, а поэтому позволяет реализовать весьма экзотические настройки. Один из примеров такой экзотики – использование механизма аутентификации exists.

Тип exists позволяет встроить в SPF произвольные имена DNS, которые генерируются на стороне проверяющего узла на основе данных конкретного подключения. То есть, эффект от работы таких фильтров нельзя предсказать простым опросом DNS – нужна ещё и SMTP-сессия.

Например, запись exists:%{ir}._relays.example.net обозначает, что нужно IP-адрес (i) отправляющего узла (как он виден на стороне принимающего) использовать в запросе A-записи в зоне _relays.example.net, и при этом запись IP-адреса нужно перевернуть по октетам (r). То есть, если почтовое сообщение пытается доставить узел с адресом 10.11.12.13, то сконструированное имя для запроса в DNS будет таким: 13.12.11.10._relays.example.net. Если IP-адрес не известен, то и обработать такой фильтр нельзя. Помимо i в спецификации определены и другие макроподстановки, например, домен отправителя, имя из EHLO/HELO и т.д. Впрочем, exists встречается даже реже, чем другой экзотический вариант – exp.

Так как собираюсь свой экспериментальный сервер TLS 1.3 tls13.1d.pw отключить, можно рассказать про сверхтехничную “пасхалку”, которая на этом сервере присутствует. Почему сверхтехничная – будет, думаю, понятно из описания.

Если посмотреть на HTTP-заголовки в ответе сервера, то можно заметить заголовок “X-TLS-ClientRandom-Challenge”, в котором написано следующее:

try="0xDEADDEADDEADC0DE0[0...]-in-Random"

Заголовок служит затравкой. Под Random – имеется в виду поле в TLS-сообщении ClientHello, поскольку сообщения сервера клиент всё равно не контролирует в нужном объёме. Поле Random – это 32 байта, отсюда многоточие в HTTP-заголовке. Вообще, если внимательно посмотреть на значения соответствующего поля (Random) в ServerHello, которое присылает экспериментальный сервер, то нетрудно заметить, что оно почти всегда (кроме случая HelloRetryRequest) равно DE:AD:DE:AD:DE:AD:C0:DE:00… (далее – нулевые байты). Конечно, это сделано специально. Обычный TLS-сервер должен писать в это поле случайные байты (ну или сигналы, разной степени секретности: самый известный сигнал – как раз признак HelloRetryRequest, значение которого прописано в RFC, но это уже совсем технические детали). Так или иначе, наличие специального HTTP-заголовка и фиксированное значение поля Random в ServerHello достаточное основание для того, чтобы попробовать прислать со стороны клиента сообщение с сигналом в Random.

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

Если ClientHello поступило с нужным сигналом в Random, то сервер встраивает в тело HTTP-ответа ASCII-рисунок, который иначе получить нельзя. В этом и состоит “пасхалка”. Надо заметить, что за все эти годы работы сервера (с 2018) было несколько успешных, – в смысле TLS-соединения, – запросов с нужным кодом в Random. Так что кто-то эту техничную “пасхалку” раскрыл.

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

DNS-серверы должны игнорировать регистр символов имени из состава запроса. Записи dXdT.RU. и dxdt.ru. – должны считаться совпадающими. Есть, впрочем, свои особенности: DNS-ответ включает в себя и имя из запроса, а одно из толкований требования об “игнорировании регистра” состоит в том, что если регистр игнорируется, то его можно игнорировать и в ответе. То есть, с одной стороны, ответ должен содержать имя в точно таком же формате, в каком оно поступило в запросе (обычно, так и происходит), с другой стороны, если считается, что при сравнении регистр не имеет значения, то имена dXdT.RU. и dxdt.ru. – равны, а поэтому можно в ответ смело писать dxdt.ru. (или DxDt.ru., например).

Тем не менее, регистр символов довольно давно предложено использовать в качестве носителя дополнительной информации – для рандомизации состава запроса. Это создаёт ещё один инструмент для защиты от атак на DNS, которые используют поддельные ответы, опережающие соответствующий запрос по времени. Подобная атака состоит, например, в том, что в адрес рекурсивного резолвера отправляется большое количество пакетов, имитирующих ответ на DNS-запрос от авторитативного сервера, но содержащих подменные данные, например, IP-адрес сервера злоумышленника в A-записи. (DNS использует UDP, поэтому такая подмена возможна на уровне транспорта.) Если рекурсивный резолвер не сможет отличить подменный пакет от настоящего, – который, хотя бы, соответствует запросу, – то в локальный DNS-кэш попадёт подставное значение, оно и будет передаваться узлам, использующим данный резолвер (это называется “отравление кеша”). Естественно, для того, чтобы атака сработала, резолвер должен ожидать ответ об атакуемой зоне, но это не так трудно организовать: есть очень популярные зоны, запросы об именах в которых регулярно возникают; кроме того, нужный запрос может быть отправлен в резолвер самим злоумышленником. Последний вариант хорошо подходит для популярных открытых сервисов DNS, таких, как Google Public DNS, где, как раз, рандомизация регистра букв широко используется (собственно, запросы со скриншота – пришли из этого сервиса).

Как рандомизация регистра символов помогает защитить DNS-ответы? Довольно очевидным способом: резолвер отправляет запрос, в котором символы имени указаны в разном регистре, тем самым кодируя некоторое битовое значение (понятно, что строчная буква может кодировать единицу, а заглавная – ноль); закодированное значение резолвер запоминает и проверяет совпадение регистра в полученном ответе. Тогда, если ответ сгенерировал кто-то, кто реально видел запрос, то этот кто-то сможет подставить правильный код в регистр символов. Схема не защищает от отправки ответа раньше настоящего авторитативного сервера (или вместо этого сервера), но от отправки ответа раньше запроса – защищает. Рандомизация параметров DNS-запроса, снижающая предсказуемость параметров ответа, реализуется в DNS и другими способами. Прежде всего, это номер порта источника (номер порта – 16-битное значение), кроме того, в запросе есть поле Transaction ID (ещё 16 бит). Регистр букв имени может добавить заметное количество значимых битов. Если, конечно, технология поддерживается на стороне авторитативных серверов. И если кто-то не решил “посигналить” строчными/заглавными в обратную сторону. В общем, много “если”. (Напомню, что полноценную защиту от подмены ответов предоставляет DNSSEC.)

Кстати, очередной пример, почему ssh forwarding не такой безопасный вариант использования ключей на удалённых системах, как может показаться: при желании, через ssh-agent обратно может приехать исполнение кода на локальной системе, впрочем, с некоторыми дополнительными “плясками” – CVE-2023-38408. Авторы, естественно, не забывают упомянуть ASLR, PIE и NX:

“Surprisingly, by chaining four common side effects of shared libraries from official distribution packages, we were able to transform this very limited primitive (the dlopen() and dlclose() of shared libraries from /usr/lib*) into a reliable, one-shot remote code execution in ssh-agent (despite ASLR, PIE, and NX)”.

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

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

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

Интересно, что внесение дополнительного слоя сохранения некоторых статистических характеристик является одной из теоретических областей создания алгоритмических закладок/бэкдоров в шифрах. Представьте блочный шифр. То есть, такой шифр, который на вход получает, предположим, строго 256 битов и 256-битный ключ, а выводит тоже строго 256 битов шифротекста. Многие современные шифры так работают. Если шифр идеальный, то вывод будет равновероятным, а для успешного поиска нужно будет перебирать, хотя бы, 2^255 вариантов.

Однако можно предположить, что специальный дефект в алгоритме создаёт недокументированное разбиение всего пространства шифротекстов на некоторые интервалы (даже не обязательно, чтобы на непересекающиеся). Попадание шифротекста в тот или иной интервал связано со значением некоторых битов ключа. Тогда, если проверка свойств шифра проводится для нескольких случайных входных блоков, даже при использовании одного значения ключа, обнаружить какие-то подозрительные разбиения не получится. Однако сторона, знающая о недокументированном дефекте алгоритма, может передать кортеж специально подготовленных блоков открытого текста, прочитать вывод шифра, определить последовательность интервалов, в которые попали блоки шифротекста, и вычислить интервал возможных значений ключа (ключ использовался один и тот же). Этот вычисленный интервал для ключа может быть небольшим, – например, 2^32 значений, – что позволяет найти ключ перебором.

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

Предположим, мы хотим идентифицировать устройство и, возможно, даже пользователя Интернета по некоторым сигнатурам, связанным с использованием различных приложений. Самая простая “сигнатура” подключения – это IP-адрес. Но тут даже слово “сигнатура” используется в кавычках, так как IP-адрес, сам по себе, это всего лишь самый очевидный и банальный “номер узла”: в современном Интернете далеко не всегда IP-адрес даже примерно соответствует реальному подключению. Трансляция адресов (NAT) используется и провайдерами доступа, и за “клиентским подключением”, и в составе VPN, и так далее. IP-адрес принадлежит к наиболее важным идентификаторам в IP-сетях, но точность конкретного адреса для нашей задачи, – то есть, как “сигнатуры”, рассматриваемой в направлении пользовательского, клиентского подключения, – не велика. Более того, задачу даже принято формулировать в других терминах: как определить, что с новым IP-адресом подключается то же самое устройство? (Вынесем тут за скобки пользователя.)

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

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

TCP предоставляет некоторое количество новых сигналов: что-то можно специально добавить, да ещё и на разных этапах установления соединения (см. SYN-куки и т.д.), при этом сам процесс установления сессии позволяет выделить дополнительные особенности – сдвиги по меткам времени, характеристики из заголовков, взятые по разным сигналам. Отдельный новый базис TCP – это номера портов, а точнее, их изменение: тут экзотические методы использования, – вроде port knocking, – вообще могут позволить узнать конкретный источник сессии без всякой привязки к IP-адресу или к параметрам протоколов более высоких уровней.

И всё же, перечисленные варианты не так уж информативны, особенно, если речь только о пассивном анализе трафика. Дополнительную информацию приносят данные из более высоких уровней. Клиентские TLS-сертификаты, сертификаты электронной подписи, криптографические ключи, передаваемые в рамках разных протоколов уровня приложений – могут достаточно точно указывать на пользователя (и могут идентифицировать устройство). DNS не так трудно снабдить индивидуальными метками: а неконтролируемые и прямые запросы в DNS делают даже те приложения, которые позиционируются как “защищённые”. Эти источники сигнатур вообще не зависят от транспортных протоколов, то есть переходят от канала к каналу без изменений. Главное – их увидеть. А про куки-файлы, HTTP-запросы, конечно, можно и не напоминать.

Знаменитая компьютерная игра Another World, вышедшая в 1991 году, исполнялась на собственной виртуальной машине: то есть высокоуровневый код игры компилировался в специальный байт-код, команды которого уже исполняла реализованная для конкретной аппаратной платформы виртуальная машина. Такая архитектура позволяет удобным способом переносить программу между платформами, а так как с 1991 года технологии существенно развились, – особенно, в аппаратной части, – то не так давно Another World перенесли на FPGA, в чём тоже помог подход с виртуальной машиной (по ссылке – подробное описание, на английском).

(Найдено на Hackaday.com.)

Метаинформация о свойствах сетевого трафика – это сведения, которые можно извлечь при помощи наблюдения за “поверхностными” особенностями того или иного протокола обмена данными. Самый простой пример – начальное установление соединения: очевидно, что если два узла обменялись начальными пакетами данных, соответствующих схеме некоторого протокола, то, как минимум, в качестве кусочка метаинформации можно записать адреса узлов, тип протокола и метку времени соединения. В моём описании протокола TLS есть небольшой раздел, посвящённый метаинформации о TLS-соединениях. Естественно, принцип подходит не только к TLS, да и далеко не только к IP-сетям или сетям передачи данных вообще. Однако в случае интернет-трафика возникают интересные возможности автоматического обогащения подобных данных.

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

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

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

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

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

Я ранее уже писал на dxdt.ru про идентификацию по цепочкам: например, про применение для деанонимизации мобильных телефонов (2010 год), про идентификацию людей по географическим координатам (2009 год) и не только.