“Пасхалка” в экспериментальном сервере TLS
Так как собираюсь свой экспериментальный сервер 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. Так что кто-то эту техничную “пасхалку” раскрыл.
Адрес записки: https://dxdt.ru/2023/08/04/10678/
Похожие записки:
- Перспективный ИИ в "разработке кода"
- Обновление темы dxdt.ru
- Gitea и омоглифы не в ту сторону
- ESNI (зашифрованное поле SNI) и системы анализа трафика
- Свойства протокола скрытого обмена сообщениями
- Трафик на тестовом сервере TLS 1.3 и ESNI
- Таблицы подстановок: картинка
- ИИ для принятия решений
- "Начала" Евклида, палеография и особенности чтения манускриптов
- ИИ с перебором
- "Блокирующие" источники случайности в операционных системах
Написать комментарий