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

Почему-то свежую (относительно) уязвимость в ядре FreeBSD (CVE-2026-101302), которая требует TLS 1.3 и находится в функциях KTLS (то есть, “выгрузки” обработки TLS-данных на сторону ядра), во внешних описаниях регулярно называют “сетевой уязвимостью”, просто позволяющей “обвалить ядро FreeBSD при помощи специального сетевого пакета, отправленного по TCP”. Это не совсем верно, и тут требуется небольшое поясение. Как сейчас модно говорить: “важен контекст”. И здесь “контекст” – в самом техническом смысле, а именно – TLS-контекст в ядре.

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

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

Давно и неоднократно писал о том, что при спуфинге спутникового навигационного сигнала может, – отчасти, – помочь аутентификация сигнала. И вот, как пишут, такую систему аутентификации постепенно внедряют в гражданский сигнал GNSS Galileo. Возможно, что уже в ближайшие год-два заработает.

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

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

В идеале, конечно, удостоверяться должны сами координаты, вычисленные “на приёмнике”, но для этого, к сожалению, протребуется активная система с двухсторонней связью. То есть, вычисленные координаты нужно передавать обратно на проверяющий спутник, который сможет подтвердить их верность. Такое возможно в системах типа Starlink.

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

Кстати, что касается выгруженной OpenAI огромной пачки (больше 700 статей!) сгенерированных ИИ/LLM “решений важных математических задач”, которую уже называют “математическим” “помойкалипсисом” (Slopocalypse). В. И. Арнольд в статье “Что такое математика”, – которая выходила в виде книги, например, в 2002 году, – в подразделе, который называется “Математическое мракобесие против Абеля и Пуанкаре”, пересказывает определение математики “по Ю. И. Манину” (и Арнольд, и Манин – среди крупнейших математиков 20-го века). Пара цитат из статьи Арнольда:

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

“[…]ведь если в результате игры с символами и получается что-либо полезное, то это просто означает, что оно содержалось уже в исходных предпосылках”.

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

В Let’s Encrypt обещают с 10 февраля 2027 года начать выпускать TLS-сертификаты на 64 дня, вместо 90-дневных. Это как раз через четыре месяца (плюс-минус), то есть, как раз закончат действовать 90-дневные сертификаты, выпущенные в первой трети ноября 2026. Процесс сокращения должен быть незаметным, но нужно заранее озаботиться автоматизацией мониторинга, проверив, что он настроен (не)правильно.

Замечу, что dxdt.blog я некоторое время назад перевёл на “сверхкороткие” сертификаты со сроком действия 160 часов, так что dxdt.blog сокращение с 90 к 64 дням не коснётся: тут и так уже меньше недели. Естественно, заказ, получение и вывод сертификата на веб-сервер dxdt.blog – полностью автоматические. И за эти несколько месяцев заметная проблема была только один раз: очередной сертификат не выпустился потому, что, из-за неполадок с измерением времени на виртуальной машине, отвалился и не сработал корректно скрипт по таймеру Systemd; ну а тот момент, что сертификат не выпустился, был, к сожалению, “пойман” лишь спустя пару часов после того, как текущий сертификат завершился. Это, конечно, проблема коротких сертификатов: времени на реагирование очень мало, dxdt.blog я администрирую сам, мне вот времени и не хватило (ну и, опять же, как только УЦ перестанет выпускать сертификаты для каких-то доменов, соответствующие сайты очень быстро “потухнут” для браузеров – тут уж ничего не поделать, система выстраивается так, что сертификат будет токеном доступа). Но, в целом, пока что всё работает.

Всегда удивляет, когда оценивают доступ к некоторому ресурсу по HTTP(S) – как доступ “только на чтение” (или “только на запись”). Речь про HTTP-клиента, который что-то загружает с “целевого” сервера. Удивительно, насколько сильно представление о “передаче данных” может абстрагироваться от реальных протоколов. Тот же HTTP – очень сложный протокол (и это даже без указания HTTP/2, HTTP/3), и там не бывает “только чтения”/”только записи”. Причём, в обе стороны. А ведь для того, чтобы получился HTTP, нужно ещё несколько слоёв пройти. И везде – сессии. А сессия – исключает “только чтение” или “только запись”.

Рассмотрим HTTPS-соединение в некоторых деталях. С этим соединением связан базовый набор транспортов. Он слоистый. У нас, – в этом примере, – HTTP работает через TLS, который работает через TCP.

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

Да, TCP-стеки обычно довольно устойчивые. Но не всегда. Главное, уже на уровне TCP клиент не просто что-то отправляет на сервер, но и получает, так что не возможны ни схема “только чтение”, ни схема “только запись”. Обе стороны пишут/читают. Обе стороны обрабатывают внешние данные, присланные другой стороной. Обе стороны вынуждены работать в некотором контексте: клиент, когда получает SYN-ACK; сервер – когда получает ACK. И это ещё только на этапе установления соединения. Но в TCP есть ещё кадры, флаги, потеря пакетов и повторная отправка. И, заметьте, дело не дошло даже до начала TLS-сессии.

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

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

Немного про развитие LLM. ChatGPT 6 Pro успешно разгадывает несложные узлы по картинке, причём не строгие схемы, а произвольно нарисованные “верёвки”. На мой взгляд, это заметное достижение. Вот посмотрите пример ниже – исходная картинка с узлами и скриншот с верной разгадкой, полученной без всякой предварительной подготовки.

Тут не просто верный ответ, – only the upper-left knot will tighten (“только верхний левый узел затянется”), – но и детальное объяснение для каждого случая. Да, это максимальная из доступных публично LLM – GPT-6 Pro (причём, согласно описанию OpenAI, несмотря на название, GPT-6 Pro – это именно другая модель, а не “долгий” вариант “обычной” GPT-6), более двух минут обработки, но всё равно – показательно.

Монета в один доллар с изображением президента Трампа (действующего, между прочим) называется Semiquincentennial Dollar.

Здесь занимательно слово semiquincentennial – то есть, это полу- (semi) пяти- (quin) вековой (centennial) – “полупятивековой” доллар (не только с Трампом, не только доллар, хотя доллар с Трампом – максимально странный).

“Полупятивековой” – это половина от 500 лет. Довольно забавный способ именования, конечно. На горизонте пяти сотен лет – довольно странно отмечать половину отдельным словом, тем более, когда это история независимости от Англии. Независимость от королевства, заметьте, но на юбилейной монете изображение действующего президента, что не совсем типично для США (а в Англии – на монетах король).

И ведь можно было бы назвать “четвертьтысячелетний” – quartamillenium, а ещё лучше – quartamilliarum (тут даже немного повеяло игровой вселенной Warhammer, которая про Великобританию, впрочем).

Понятно, что латинская классическая форма, конечно, это никакой не “миллениум”, а просто ducenti quinquaginta anni – двести пятьдесят лет.

Кто бы сомневался, но, как и следовало ожидать, в октябрьском обновлении “Коуровской тетради” много задач, явно отмеченных как решённые “с использованием AI”. Есть там среди многих и решение для задачи 11.115 (“unverified AI solution”), про которую я писал: точно тот же контрпример, что упоминается и на dxdt.blog, но в записке про то, как я проверял возможности Claude Fable 5/Opus 5 по конструированию контрпримеров сразу с доказательством на Lean. У меня используется квадрат элемента группы, а в опубликованном контрпримере (M. Kinyon, J. Urban) – указана степень m≥2 – понятно, что m == 2 подходит. Цитата из моей записки:

[…] если кому-то интересны супертехнические подробности, то вот: построим подгруппу на словах с чётными и нечётными степенями (это отображение в Z/2Z), и подгруппу на соотношениях с a^2.

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

Из сентябрьских записок 2026 года отдельно отмечу пять:

• Вращение Земли, день, ночь и новинки GPT
• Проверка компьютерных доказательств компьютером
• Арифметика Диофанта и вторая задача
• Аутентификация клиента и перехват TLS средствами MITM
• Пробное расшифрование и скрытые сетевые сервисы

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

we have signed a definitive agreement to acquire an established, broadly trusted root from GlobalSign (мы подписали итоговое соглашение, чтобы приобрести действующий корень GlobalSign с повсеместным доверием).

Так-то. Интересное развитие.

На фото ниже – антикварная шведская шкатулка, явно предполагавшая использование двух замков.

(Tomas Näslund/Vindelns hembygdsförening, источник; датировка не ясна, но, судя по всему, позже 18 века.)

Эта шкатулка явно не древняя, хоть и старинная, однако прочные сундуки и секретные коробки с двумя замками использовались ещё в древнем Риме. Сценарии использования могли быть разными.

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

Итак, сама схема. Есть две стороны, A и B. Сторона A хочет отправить стороне B секретную записку с недоверенным курьером. Общего механического ключа, – чтобы на стороне A запереть шкатулку, а отпереть на стороне B другой копией ключа, – нет. Как поступить?

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

Что тут было бы предварительным распределением ключей? Да самое простое решение: сторона А и сторона B могли бы просто иметь копию ключа к одному замку, которым запирается шкатулка. Это простейший вариант. Если нужна схема посложнее, с разными ключами, то можно взять шкатулку со специальным замком: такой замок позволяет открыть шкатулку любым ключом из двух разных (этого несложно добиться: например, засов внутреннего замка на два ключа имеет два направления для открывания, каждое направление запирается “личинкой” под свой ключ). Понятно, что эти схемы сильно отличаются от исходной: один замок – два ключа. Ключ как-то нужно отправить второй стороне, если нет доверенного канала передачи ключа, то схема теряет секретность: ключ могут скопировать “на транзите”, и потом незаметно открыть шкатулку.

Какие есть особенности у схемы с двумя замками? Первая, самая главная: ключи не покидают пределы доверенного периметра. За периметр уходит только запертая шкатулка. Вторая особенность: заперев внутри шкатулки записку, сторона А уже не может поменять содержание записки, если шкатулка попала к стороне B. Третья особенность: сторона B – получит ту же самую записку, которая размещена в шкатулке изначально, но с двойным подтверждением, так как сторона-отправитель (сторона A) и поставила замок, и сняла его (подтверив, что есть ключ). Например, все эти особенности используются в статье “Покер в уме” (“Ментальный покер”, Shamir, Rivest, Adleman, MIT-LCS-TM-125, 1979), где и описана исходная схема (авторы указывают, что её предложил М. Рабин), но со многими шкатулками и для игральных карт.

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

Это, вообще говоря, неустранимая особенность подобных схем. Как ни странно, проявляется и в современной криптографии: например, такой же атаке подвержена схема Диффи-Хеллмана.

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

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

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