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. Так что кто-то эту техничную “пасхалку” раскрыл.

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

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

Вообще, блок постулатов озаглавлен Αἰτήματα – “Требования”, но принято называть эти требования “постулатами”. Пятый постулат, как известно, делает геометрию евклидовой. Содержательная часть его формулировки, в общем смысле, вводит ограничение на количество различных прямых, параллельных данной, которые можно провести через точку, не лежащую на данной прямой (здесь – одну и только одну параллельную можно провести). Однако классическая формулировка другая, она обычно оперирует двумя прямыми, на которые падает третья – см. перевод ниже. При этом и классических формулировок – много, они отличаются в деталях. Так, вариант, записанный в рассматриваемом манускрипте, содержит занятное дополнение. (Помимо прочего, постулат про “параллельные прямые” регулярно неверно излагается или ещё как-нибудь странно используется в современном “научпопе” и другой литературе.)

Читать древний шрифт сложно: тут не только лигатуры и прочие сокращения норовят ввести в заблуждение, но и начертания букв запутывают. Посудите сами: в пятой строке, например, слева, сразу после запятой, написано ἐκβαλλομένας, но букву β узнать непросто – здесь она скорее как современная рукописная русская “и” (строчная). В современной древнегреческой типографике текст со скриншота манускрипта (начиная с вертикальной красной черты) выглядит так:

Καὶ ἐὰν εἰς δύο εὐθείας ἐυθεῖα τις ἐμπἱπτουσα τὰς ἐντὸς καὶ ἐπὶ τὰ αὐτὰ μέρη γωνίας δύο ὀρθῶν ἐλάσσονας ποιῇ, ἐκβαλλομένας τὰς δύο εὐθείας ἐπ’ἄπειρον συμπίπτειν ἁλληλάις ἐφ’ ἅ μέρη εἰσὶν αἱ τῶν δύο ὀρθῶ(ν) ἐλάσσονες: καὶ δύο εὐθείας χωρίον μη περιέχειν.

Не литературный, но близкий к оригиналу, перевод, разбит на две части: 1) “И если одна прямая, падающая на две других, внутренние и по одну сторону углы меньше двух прямых [углов] образует, продолженные без ограничений две другие прямые встретятся на той стороне, на которой углы меньше двух прямых”; 2) “И две прямые пространства (области) не охватывают”.

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

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

• “Лазейки” вокруг неравенства Белла;
• “Инспекция” трафика с сохранением конфиденциальности;
• Бункеры в Fallout;
• Уровни сигнатур клиентских подключений;
• Общее представление о шифрах и бэкдоры.

Известно, что греческая буква “о-мега” это, в каком-то смысле, дважды буква “о-микрон”. Если точнее, то “о-микрон” – краткое О (“микро-о”), а “о-мега” – большое или долгое О. Занятно, что в некоторых старинных рукописных начертаниях омега как раз и записывается как два омикрона. Подтверждающий скриншот из манускрипта Urb.gr.15 (“Слова” Григория Богослова, десятый век):

Например, в конце второй (на скриншоте) строки, слово προθύμως – отчётливо видно, что буква ω построена в точности как пара склеенных ο. Такое же начертание омеги нетрудно обнаружить и в первой строке, в слове ἡμῶν (локализация границ самого слова, впрочем, может оказаться затруднительной, если оно не знакомо читателю). А вот пара “омикронов-окружностей”, придавленных сверху чертой – это тоже π.

При изучении скриншота может показаться, что там присутствуют некие “велосипедные” двойные омикроны в начале и в конце первой строки, но нет – это сигма и омикрон в слове ὅσοι.

Кстати, в палеографии этот вариант рукописного древнегреческого называется “минускулом типа bouletée”, а такая запись омеги – один из характерных признаков. (Наверное, скоро можно уже не отмечать записки про древнегреческий и палеографию как офтопики.)

Если вы управляете авторитативным сервером глобальной 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.)

Картинка ниже иллюстрирует эффект применения таблицы подстановок (π) из состава шифра “Кузнечик”: верхняя часть – это последовательно увеличивающиеся (слева направо или наоборот – как хотите) значения байтов, биты конкретного байта записаны вертикально, синий пиксель – единица (или нуль, но тогда зелёный – единица); нижняя часть – замена по таблице подстановок, где байт в данном столбце заменяется на соответствующее значение из таблицы. Способ применения таблицы максимально простой – значение входного байта заменяется на байт из таблицы, соответствующий по номеру, например, 0x00 заменяется на 0xFC и так далее, для каждого значения от 0x00 до 0xFF. Состав подстановок зафиксирован спецификацией шифра.

Хорошо виден основной эффект: в результате замены, расстояние между байтами возрастающей последовательности увеличивается, а “статистика”, порождаемая алгоритмом (n+1), скрывается. Подобные таблицы замены относятся к основным элементам, используемым при построении современных шифров. Естественно, сама по себе таблица никакой стойкости не обеспечивает, но, например, решает важную задачу “быстрого” размывания последовательностей “близких” значений во входных данных. Значения для замены специально подбираются так, чтобы эффективно решать именно эту задачу. От таблиц замены зависит стойкость шифров, так что исследование их свойств имеет большое значение (в том числе, с точки зрения обнаружения возможных архитектурных бэкдоров), в частности, конкретно с таблицами “Кузнечика” связана целая серия работ, но это тема для другой записки. Возможно, я напишу подробное описание работы шифра “Кузнечик” для dxdt.ru. С цветными картинками. (“Магма”, второй шифр из соответствующих ГОСТ, – достаточно давно подробно описан.)

В 2018 году я разработал и опубликовал по адресу tls13.1d.pw тестовый сервер для проверки приложений, поддерживающих TLS 1.3. Строго говоря, тогда именно TLS 1.3 (в смысле обозначения версий) ещё не было, а был черновик спецификации, которую, в экспериментальном режиме, поддерживали некоторые распространённые клиенты, например, браузеры Chrome и Firefox. На серверной стороне дело обстояло похуже – поддержки в стабильных версиях распространённых веб-серверов не было совсем.

Сейчас TLS 1.3 стал типовой, очень распространённой версией TLS, используемой в вебе (и не только в вебе), поэтому, думаю, тестовый сервер больше не нужен: отключение tls13.1d.pw я запланировал на конец августа 2023 года (возможно, раньше).

Собственно, всякий современный TLS-сервер для HTTPS должен поддерживать TLS 1.3 в качестве основного, а TLS 1.2 – в качестве “запасного” варианта. Прочие версии можно отключить, ну, кроме весьма редких случаев, когда требуется совместимость с очень старыми приложениями – к сожалению, некоторым веб-сервисам приходится тянуть поддержку старых клиентов. Однако для остальных – можно даже оставить только TLS 1.3: этот протокол портировали на самые старые и экзотические системы. Кроме того, TLS 1.3, на данный момент, лучшая версия, которая архитектурно превосходит все предыдущие.

(Update, 09/09/2023: сервер пока что восстановлен и работает – подробности.)

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

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

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

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

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

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

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

Кстати, очередной пример, почему 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 значений, – что позволяет найти ключ перебором.

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