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

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

(Кстати, об особенностях мультиплексирования HTTP/2 регулярно забывают, что приводит к попыткам ограничить поток HTTP-запросов для проксирующего веб-сервера, который работает по HTTP/2, “силами iptables” по TCP-соединениям.)

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

Есть занятный, пусть и не самый точный, способ определения того, что какой-то глобальный и маршрутизируемый IP-адрес соответствует anycast-узлу: нужно измерить время ответа (ICMP) при помощи утилиты ping, но сделать это из двух базовых точек, заведомо находящихся в существенно разных регионах, а потом измерить ping между этими точками. Если сумма для времени от точек измерения до измеряемого узла существенно меньше, чем время между базовыми точками, то, скорее всего, тут присутствует anycast. Это неравенство треугольника, и оно тут при помощи anycast нарушается.

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

Развитие полузабытого проекта “Яндекс.Рефераты”: нейросеть YandexGPT “сдала” ЕГЭ по литературе, при этом “усреднённая оценка составила 55 баллов”, что подстёгивает “хайп”, так как, якобы, позволяет поступить в вуз. Интересно, смогла бы данная нейросеть хотя бы заполнить бланк ЕГЭ?

Кстати, цитата из недавнего вывода данной нейросети: “число делится на 2 и на 11, а значит, делится и на 3”. (Новое средневековье уже со всех сторон.)

Выпустил ежегодное обновление технического описания TLS, которое я поддерживаю: в этом году лишь добавил в раздел “TLS и постквантовая криптография” краткое изложение внедрения X25519Kyber768 в браузере Chrome (и то – только про интеграцию в схему TLS; в принципе, это уже публиковалось на dxdt.ru).

Открытый ключ Kyber768 (постквантовой криптосистемы) – это 1184 байта, то есть, 9472 бита. Это заметно больше, чем занимает практический 8-килобитный ключ RSA. Для взлома такого RSA-ключа на квантовом компьютере (весьма гипотетическом), требуется количество логических кубитов в разных регистрах не меньше 24576 == 8K * 3. Но это теоретический минимум для логических кубитов, без учёта квантовых схем и возможной физической реальности. Поскольку технологические принципы реализации алгоритма Шора пока что не известны, оценки того, сколько физических кубитов и квантовых элементов потребуется для подобной разрядности, затруднены и сильно различаются, но нетрудно получить оценку в миллион (и более). И этот миллион квантовых эллементов, к тому же, может не сработать.

Естественно, это не отменяет того, что Kyber768 тут выглядит лучше, если обладает классической стойкостью. Кроме того, RSA – устаревшая криптосистема, а для коротких, относительно RSA, ключей ECDSA (например) – и кубитов потребуется поменьше, при этом прямо “растягивать” ту же ECDSA на несколько килобит – так себе идея.

Обновил раздел “Избранные записки“, добавил пять новых:

• “Лазейки” вокруг неравенства Белла
• Превентивное удаление “цифровых следов” и художественное произведение
• Рандомизация регистра символов в DNS
• Кибератаки, самоуправляемые автомобили и бот в смартфоне
• Геопривязка в персональных цифровых финансах

Один из самых старых способов скрытого получения доверенного доступа к не менее скрытым сервисам в Интернете (как IP-сети) это port knocking (метод “секретного портового стука”). Суть метода изложить не трудно: скрываемый сервис работает на закреплённом за ним номером порта, но доступ для TCP-соединений (например) к этому номеру порта открывается только для тех IP-адресов, которые выполнили установленный набор попыток подключений по другим номерам портов. Чуть более развёрнутое объяснение для тех, кто не сетевой инженер (опять же, используем TCP): TCP-соединение – это соединение “точка-точка”, на каждом из концов соединению соответствует IP-адрес и номер порта, где номер порта, можно считать, это просто 16-битное число; например, 10.11.12.13:14395 -> 10.101.102.103:22 – соединение клиента с номером порта 14395 на серверный номер порта 22 (это обычный номер для SSH); предположим, что доступ на сервере по порту 22 закрыт межсетевым экраном (брандмауэром), то есть, попытка соединения на этот номер порта будет проигнорирована сервером; но если некоторый клиент с IP 10.11.12.13 выполнит попытки TCP-подключения на другие номера портов сервера по заданной ключевой последовательности: 1011, 1022, 1033, то брандмауэр, который фиксирует у себя попытки подключения, откроет подключения по номеру порта 22, но только для соответствующего IP-источника.

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

Почему-то данный метод и известен не столь широко, как можно подумать, да и нередко его необоснованно относят к способам защиты из разряда Security through obscurity (“Безопасность через неясность”, в одном из переводов), которые, как бы, “заведомо слабые”, что как раз и есть хороший пример неверного обобщения “принципа Керкгоффса”. Однако данный метод хорош, если используется по назначению и в верном контексте. А если излишне настойчиво обобщать, то и авторизация SSH по ключу может показаться “безопасностью через неясность” – действительно, а как если бы он знал значения байтов секретного ключа и их последовательность? Впрочем, это лирическое отступление.

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

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

В октябре 2008 года, пятнадцать лет назад, на dxdt.ru, например, вышла записка про загадочную программу DARPA GANDALF – носимую систему поиска, идентификации и определения координат радиопередатчиков:

В принципе, сигнал всякого реального передатчика обязательно имеет свои индивидуальные особенности, обусловленные специфическими характеристиками конкретных экземпляров аналоговых схем-цепей-устройств в этом самом передатчике. Другое дело, что выявление и “атрибуция” этих особенностей не в лабораторных условиях – задача, разрешимая скорее теоретически, но не практически.

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

Атака Блейхенбахера, использующая дефекты дополнений в RSA при RSA-шифровании, всё ещё работает на практике для многих приложений (пусть и с оговорками), что показано в практическом исследовании под названием The Marvin Attack (Hubert Kario, RedHat). Исходной атаке, заметьте, 25 лет с момента публикации. RSA, конечно, устарела, – особенно, в роли RSA-шифрования, – а в современных TLS-решениях (например) не должна бы использоваться, однако пока что никуда не девается из приложений, далеко не только в TLS.

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

Что бы это могло означать? Скорее всего, на целом папирусе в этом месте была записана другая, более старая, версия строки 6.4, оканчивающаяся другим словом: στομαλίμνης. Полностью так: “μεσσηγὺς ποταμοῖο Σκαμάνδρου καὶ στομαλίμνης” (дословно: “между рекой Скамандр и лагуной/лиманом”), и эта версия длиннее, чем “современный” вариант, как в Venetus A, поэтому последнее слово могло “уехать” (“The Ptolemaic papyri of Homer”, Köln: Westdt. Verl. 1967). Кусок буквы как раз похож на μ, а возможно, что и на μν тоже тянет.

Считается, что на современный вариант, с потоками (ῥοάων) Ксанфа, мог переписать Аристарх Самофракийский или кто-то из работавших с ним. Версия со Скамандр-рекой указана в комментариях на полях цитируемого манускрипта Venetus A: там буквально написано, что вариант Скамандр-реки и лагуны записан в “старом тексте”, но его поменяли, – поменяли раньше, не в момент записи Venetus A, – на Симоент и Ксанф, потому что (Аристарху) так показалось географически точнее по событиям сеттинга. Кстати, строка в переводе Гнедича: “Меж­ду бре­гов Симо­иса и пыш­но­ст­ру­и­сто­го Ксан­фа” (почему “пышноструистый” – не ясно, но это всё известные особенности перевода Гнедича).

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

(На кусочке папируса. 230 г. до н.э. Сомнительно, конечно, что там “Ν”.)

(Манускрипт Venetus A. 10 в.)

(Современный веб-браузер. 2023 г.)

Естественно, сотрудник скриптория, который записал Venetus A, тоже мог пользоваться источниками, которым было по тысяче или около того лет (оно примерно так и считается сейчас).

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

В сентябре 2023 года на dxdt.ru записки выходили часто, так что некоторые можно снова отдельно отметить:

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

Простой пример “про измерения” – о сложностях работы с погрешностями, которые не отражают в тематических статьях СМИ;

VPN и DNS-сервисы с ECS: утечка сведений об адресах – сервисы DNS-резолверов могут выносить наружу данные об исходном сетевом подключении клиента;

Технические подробности: постквантовая криптосистема X25519Kyber768 в TLS – описание некоторых деталей использования криптосистемы с постквантовой стойкостью, которую недавно внедрили в браузер Chrome;

Квантовые компьютеры и аксиома непрерывности – как себе представлять квантовый компьютер и как его (гипотетическая) работа связана со свойствами онтологической границы между макро- и микрообъектами.