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

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

Личинка заблокировала собачку в замке.
(1) Из-за перекоса.
(2) В одной из комнат.

(Развитие темы: “Квантовые вычисления для филологов“.)

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

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

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

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

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

(Я уже писал о полностью зашифрованных протоколах раньше, в том числе, про распределение ключей и влияние TLS.)

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

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

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

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

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

А так, конечно, “компьютер не может ошибаться“.

– Зачем вы устраиваете эту симуляцию вселенной?
– Чтобы проверить, что симуляция вселенных вообще возможна.

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

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

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

Почему “спагеттизация” Интернета не относится напрямую к технологиям создания, собственно, “каналов связи”? В принципе, на уровне от “физического порта” до “физического порта” сейчас тоже присутствует виртуализация, а создание туннелей под собирательным названием “L2VPN/MPLS” – вполне себе распространённая практика. То есть, трафик и на этом уровне может ходить замысловатыми путями, тут имеется собственная маршрутизация, хитрая динамическая коммутация и прочие занимательные инструменты. Это так, однако Интернет – это IP плюс автономные системы с BGP (и плюс DNS, конечно), а также более или менее непрерывная, в смысле IP/BGP, “глобальность” (которая пока что ещё остаётся доступной на практике). “Глобальность” важна потому, что IP-сети повсеместно используются и вполне себе изолированные. Но, конечно, элементы “битвы за банхаммер” наблюдаются и на уровне “отключения канала и портов доступа”.

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

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

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

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

В продолжение предыдущей записки о том, что Google успешно строит наложенную сеть для защищенного доступа своего браузера к веб-ресурсам. Интересно, что у Google информация о том, какие ресурсы посещал пользователь браузера, естественным образом сохраняется, поскольку для доступа к сети потребуется google-аккаунт. Не обязательно, чтобы историю прямо выдавал только браузер – собирать данные можно и при помощи веб-счётчиков Google Analytics, которые установлены едва ли не повсеместно.

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

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

Что касается проксирования трафика, встраиваемого Google в браузер Chrome, и как такая технология вообще может выглядеть в своём развитии.

1.

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

2.

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

3.

В описании конкретно той технологии, которую внедряет сейчас Google, отдельно сказано про сохранение некоторой “географической привязки” (GeoIP) – предполагается использовать для выходных узлов IP-адреса, “представляющие примерную геолокацию пользователя, в том числе, страну”. За этим вовсе не обязательно должен стоять комплект физических прокси, расставленных по разным странам в соответствии с геопривязкой входных узлов. “Геолокация” – это полностью независимый от IP-сети метод, в котором IP-адрес используется просто как “ключ для поиска”. Поэтому, например, Google может предоставить API, позволяющий получать геолокацию по выходным узлам их наложенной сети, или встроить “размытую геолокацию” в качестве дополнительного параметра запроса браузера (уже есть поддержка), или даже просто описать административную принадлежность в базах данных соответствующих IP-регистратур, но не менять сетевое расположение точек выхода. Сами же сетевые подключения уровня IP для выходных узлов могут находиться где угодно (заметьте, что адрес, административно приписанный к организации в той или иной стране, сейчас можно унести в любую точку Сети даже на уровне виртуализации каналов связи, то есть, ниже IP/BGP).

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