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

Всегда ли требуется знать значение секретного ключа, чтобы провести ту или иную атаку на систему аутентификации с подменой стороны? Вовсе нет.

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

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

В канале Бориса Трушина попался скриншот вопроса на некотором телевизионном шоу: “Площади каких двух фигур ни при каких размерах не могут быть в точности равны?”; варианты ответов: “A) круга и квадрата; B) треугольника и ромба; C) трапеции и параллелограмма; D) прямоугольника и пятиугольника”. Вроде, это уже достаточно старая задача. С одной стороны, очевидно, что верного ответа среди вариантов нет, с другой стороны, не менее очевидно, что же имели в виду составители сценария и какой ответ назначен правильным: такое вот преломление “квадратуры круга”, видимо. Ну, а с третьей стороны, если рассматривать равенство площадей в смысле равносоставленности и снять некоторые подразумеваемые ограничения, то и вообще может возникнуть задача, известная как “Квадратура круга Тарского”, вместе с дополнительными трудностями в определении “верного ответа” через бесконечные процессы.

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

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

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

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

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

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

Не литературный, но близкий к оригиналу, перевод, разбит на две части: 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: сервер пока что восстановлен и работает – подробности.)

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

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

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

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

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

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