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

Если вы записываете IP-трафик на промежуточном узле, то можно ли в записи обнаружить использование в TLS-сессиях серверных TLS-сертификатов, выпущенных от нестойких ключей доверенного УЦ eMudhra? Можно, но не всегда.

Дело в том, что в TLS 1.3 сообщение с серверными сертификатами уже зашифровано, поэтому, простым способом, не зная сессионных ключей, увидеть, какие там сертификаты – не выйдет. Но в TLS до версии 1.3 – можно непосредственно видеть сертификаты в дампе открытого трафика.

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

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

Почему вообще такие TLS-сертификаты могли использоваться? В теории, распространённые браузеры должны проверять метки логов Certificate Transparency в сертификатах, и если сертификат не имеет валидных меток доверенных логов, то браузер не должен верить в такой сертификат. Метки логов можно получить штатным образом, зная подписывающий секретный ключ УЦ. Но дело даже не в этом. Дело в том, что далеко не только браузеры используют TLS. А различные прочие клиенты, которых много разных, вовсе не проверяют метки логов и не требуют их наличия в сертификате. Так что подмена работала (и работает) для многих устройств и приложений. Один из шумных практических примеров – неожиданно грубая ошибка в ПО такого устройства, как “Яндекс.Станция”, позволившая атакующему подставлять свой программный код при помощи атаки типа “Человек посередине”, с использованием тех самых тривиальных ключей eMudhra. Шумность данной проблемы обсуловлена тем, что тривиальность ошибки может легко посморить с тривиальностью самих ключей: доверенных “из коробки” УЦ – сотни, и устройство не может их никак контролировать, проверять нужно отпечатки ключей, а не доверять только коробочным УЦ.

Так что практических случаев применения скомпрометированных ключей очень много. И трудностей тут добавляет то, что проблемные ключи были подписаны другим доверенным УЦ – Sectigo, который горазодо более распространён. То есть, чтобы атака сработала – было достаточно доверия корневым ключам Sectigo.

Итак, в принципе, использование подменных сертификатов, выпущенных от триваильных ключей, можно увидеть в записи трафика, и такие сертификаты могли использоваться ранее. Однако если запись трафика не велась, либо если атакуемым устройством/приложением использовалась только актуальная версия TLS 1.3, где сертификаты передаются в зашированном виде, увидеть уже ничего не получится. Как говорится, “были сертификаты или нет – науке это не известно”. Однако с точки зрения теории защиты информации необходимо считать, что сертификаты такие были. И речь тут – только про TLS, но X.509-сертификаты используются и в других областях.

Пять записок, которые вышли в октябре 2026 года, отмечу отдельно:

• Сложности запросов и “только чтение”
• Электронная подпись и GNSS Galileo
• Системы Let’s Encrypt и статистика
• Отпечатки ключей и практика TLS
• Что означает компрометация ключей УЦ eMudhra на практике

Колонка Дмитрия Буркова про ИИ/LLM в Интернете – почитайте. Цитата:

Вокруг ИИ продают обещания и страхи. Сценарий уничтожения человечества звучит громче вопросов о полномочиях. Но громкость не говорит о вероятности и не объясняет, что защищать сегодня.

Фотография китайского космического самолёта размещена в публикации DIA (штатовское Defense Intelligence Agency):

Качество опубликованного снимка, конечно, так себе. Сфотографировано на орбите, аппаратом, принадлежащим Maxar, видимо, с большого расстояния. Снизу, вроде как, прикреплён другой спутник, с раскрытыми солнечными панелями.

(via)

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

А именно, то, что в англоязычной традиции называется Baby-Step Giant-Step (BSGS), известно как алгоритм Гельфонда (или Гельфонда-Шенкса) для дискретного логарифма; а вторая часть – разностный метод, – это, в принципе, обобщение предыдущего алгоритма, но с использованием других таблиц. Оба алгоритма на практике могут успешно работать только с небольшим подмножеством скаляров (потому что выигрыш там достигается из использования предвычисленных таблиц, но уже 2^64 – это слишком много по памяти). Этого оказалось достаточно, в данном практическом и шумном случае. Опять же, это математические детали.

Главное тут в другом – данный глобальный практический случай с eMudhra идеально отвечает на всякие сомнения в практической полезности изучения тривиальных логарифмов на эллиптических кривых: даже Google не использовал эти проверки, из-за чего глобальные программы доверия корневым ключам в браузерах оказались скомпрометированы на долгое время. Так что тема оказалась более чем к месту.

Что ж, в Google хотя бы прямо признали, что проблема с тривиальными ключами была на их стороне тоже: требуемая базовая проверка для ECDSA вообще не выполнялась, поэтому тривиальные ключи от eMudhra прошли в программу и оставались незамеченными очень долго. Цитата:

However, prior to this incident, standard linting tools focused on algorithmic checks for RSA/DSA and blocklist checks for ECDSA; they had not implemented the Baby-Step Giant-Step (BSGS) discrete logarithm checks for small EC private scalars or pairwise EC key differences that paranoid_crypto includes.
(Тем не менее, до этого инцидента, типовые инструменты линтинга были сфокусированы на проверке RSA/DSA и списках заблокированных ключей для ECDSA; инструменты не поддерживали проверку методом малых и больших шагов для дискретного логарифма с малыми секретными скалярами или попарную разностную проверку, как это реализует paranoid_crypto.)

Пишут, что уже исправлено. Посмотрим.

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

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

Не сомневайтесь, именно так и было: ключи промежуточных УЦ уже много лет, по условиям тех самых программ доверия браузеров, необходимо предъявлять сразу после выпуска, это строгое требование; на тривиальных ключах была поставлена кросс-подпись другого хорошо известного доверенного УЦ (Sectigo). Тут целый ряд авторитетных корпораций (Google, Mozilla, Microsoft, Apple) – законодатели мод и локомотивы разнообразных требований и рекомендаций, ограничивающих участие в программах доверия. Для безопасности.

Однако в программе явно “что-то пошло не так”. Поэтому реальная проблема – гораздо больше и основательнее.

Но почему-то заметают её под ковёр.

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

Предположим, что обмен данными организован в виде кадров. Одна из сторон передаёт кадр (и внутри него – пакет) с запросом, а потом переключается на приём, ожидая начальный символ, задающий кадр для ответа. И вот пусть это время ожидания – 10 микросекунд (μs), с момента завершения передачи. Если через 10 микросекунд начало кадра не получено, то узел считает, что ответа нет. Это, например, очень похоже на “классический” Bluetooth, если хотите ближе к практике.

Что означает такая схема? Она означает, что сигнал должен “сбегать” в обе стороны за 10 микросекунд, без учёта обработки. То есть, мгновенный ответ на второй стороне означает, что доступное плечо – 5 микросекунд. Или, если посчитать в метры, проходимые электромагнитным импульсом, то около 1500 метров. Дальше, как бы не увеличивалась мощность сигнала, чувствительность приёмного тракта, – работать не будет: потому что мощность тут никак не позволяет уменьшить время задержки, и если ответ пришёл с задержкой больше 10 микросекунд, то приёмник его уже не прочитает.

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

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

Кстати, насчёт доверенных меток логов Certificate Transparency и тривиальных ключей УЦ eMudhra: теперь соответствующих оконечных сертификатов в публичных CT-логах нашли уже больше 100 тысяч. Данные сертификаты (и пресертификаты), естественно, были выпущены после 20 октября (когда история с ключами стала совсем публичной). Понятно, что выпустить такой сертификат может всякий желающий. А пока операторы CT-логов не отозвали доверие – можно эти самые CT-логи данными сертификатами заливать.

Однако момент с успешным размещеннием в CT-логах подтверждает то, что получить SCT-метку, при желании, не составляло никакого труда. Да, отметка, скорее всего, появилась бы в CT-логах, но за этим не особенно-то следят даже операторы логов. Ну и более того – метки и сертификаты продолжают действовать в том ПО, настройки которого не поменялись. То есть, браузер, который не обновился, и который требует SCT-меток, будет признавать такой сертификат валидным; при прочих равных, конечно: должен быть период действия подходящий, не должен проверяться статус промежуточных сертификатов, должны в оконечном сертификате быть прописаны адреса точек проверки статуса – CRL и/или OCSP, – и т.д., и т.п., что, впрочем, ничуть не улучшает ситуацию.

Удивительно, что во многих проектах, оказывается, TLS с сертификатами “из коробки” используется для подтверждения не только источника, но и подлинности важных данных (например, кода обновления и т.д.). То есть, если узел-источник аутентифицирован в рамках коробочного TLS, относительно внешних УЦ, то и все данные, полученные с этого узла, подлинные – потому что источник, как бы, подлинный. Cейчас этот момент, – “неожиданно!”, – обсуждается. Естественно, в свете истории с тривиальными ключами удостоверяющего центра (УЦ) eMudhra, которые, несмотря на свою тривиальность, упешно и без вопросов были включены во все распространённые программы доверия CA/B-форума, в том числе, в браузеры от Google и Mozilla (к большому сожалению), где и находились больше года.

Вообще, если у вас приложение, которое скачивает обновления или ещё какие-то важные данные, то TLS тут можно и нужно использовать, но хорошо бы понимать, что и как там работает. То есть, тут однозначно нужен и key pinning, и дополнительное (помимо TLS!) удостоверение подлинности данных. То есть, данные в любом случае должны быть подписаны от доверенных ключей, и доверие должно быть зашито в приложение помимо внешней системы УЦ. Казалось бы, это хрестоматийные азы данного направления. И тем не менее – не везде таким правилам следуют.

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

Действительно, даже в начале моего собственного описания TLS написано, буквально, следующее:

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

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

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

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

Почему вообще возникает проблема? Потому что открытая схема использования TLS, – например, в вебе, для HTTPS, – предполагает, что клиент не может заранее узнать значения ключей. Это совершенно верное, логичное допущение. В нём и смысл – нужно сделать так, чтобы доверие можно было распространять на новые ключи ранее неизвестных узлов, автоматически. TLS это позволяет реализовать. Но нужно создать общий список доверенных ключей третьей стороны. Отсюда возникает инфраструктура УЦ.

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

Смотрел код библиотеки Go crypto/x509 на предмет того, как там разбираются конкретные поля сертификата. Сразу наткнулся в parser.go на опечатку в стиле copy-paste: текст ошибки при некорректном Subject взят из блока, где так же обрабатывается Issuer; соответственно, текст сообщения об ошибке вводит в заблуждение – при некорректном поле Subject будет выведено, что “x509: malformed issuer”, а должно быть: “x509: malformed subject”.

Ну, думаю, исправление одной строчки – отправлю коммит через социальную сеть GitHub, потому что у меня там есть аккаунт всё равно (что поделать). Внёс исправление, подготовил pull request (черновик). Однако в черновик pull request (PR) сразу бот от Go написал, что, мол, для рассмотрения PR мне нужно какую-то дополнительную лицензию Google CLA подтвердить (забавно, да – уже для рассмотрения). Закрыл PR тут же. Может, кто ещё исправит.