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

Так как собираюсь свой экспериментальный сервер 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 год) и не только.

Посмотреть, как в “Яндекс.Браузере” работает шумно анонсированная возможность под названием “Краткий пересказ” (“нейросеть сделает краткий пересказ статьи”) – не удалось: я даже специально установил “Яндекс.Браузер” под Debian 11 в отдельную виртуальную машину, но кнопка “пересказа” не отображается. Ну и ладно. К браузеру, как техническому инструменту, эта новая возможность всё равно отношения имеет крайне мало, однако очень хорошо укладывается в популярную сейчас понятийную канву, когда полезность подобных “автоматизаторов” объясняется “нехваткой времени”, а использование мотивируется экономией пятнадцати минут, вместо того, чтобы проверить полезный навык извлечения смыслов первого слоя. (Почему, кстати, вообще предполагается, что тут есть “экономия”? Вопрос риторический. Чтение пятидесяти кратких выводов синонимайзера-переростка тоже отнимает время; далеко не факт, что с какой-то пользой; шансы обнаружить в результате действительно полезный материал – не факт, что велики.)

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

С автономными такси-роботами возможны ситуации, когда это такси везёт пассажира куда-то “не туда” или, например, просто остановилось на дороге и не выпускает. Нетрудно предположить, что точно такие же ситуации возможны и в случае с такси, которым управляет водитель-человек. Однако вариант с роботами – отличается, и отличается столь же существенно, как и все подобные “автоматизации”, потому что автоматизация тут автоматизирует и атаки.

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

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

Так что роботы-такси вовсе не обязательно делают систему безопасной, поскольку возникают новые варианты атак и новые уязвимости.

В статье из 2019 года, посвящённой блокировкам и блокированию протоколов в Интернете, я писал вот что:

Среди перспектив развития систем контроля трафика (именно контроля) можно отметить пропуск только авторизованного трафика. Конечно, такой вариант пока кажется фантастикой. Авторизация трафика — это развитие схемы с белыми списками. В этом случае доступ по спискам IP-адресов и имен не ограничивается, но промежуточные узлы пропускают только трафик, который содержит специальные криптографические маркеры, подтверждающие его легитимность.

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

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

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

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

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

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

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

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

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

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

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