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

У меня на сайте используется открытый ключ, который начинается с 0xDEADC0DE. Но вообще-то TLS-сертификат может служить и носителем целого текстового сообщения-декларации. Получается что-то вроде документа, который протестует против инфраструктуры УЦ, сложившейся в вебе. Создание такого сертификата описано на сайте Maurycyz.com. Текст сообщения виден в Base64, то есть, чтобы его прочитать – нужно вывести серверный сертификат в PEM (PEM представляет собой Base64-запись DER-представления, помещённую между текстовыми строками вида “BEGIN/END”). Выглядит это так:

Работает это вот почему: опубликованная строка текста является корректным Base64-кодом; сертификат использует RSA, значение модуля ключа RSA можно подобрать под нужный код Base64 обратным преобразованием, вычислив подходящий простой делитель, это вычислительно быстро, так как исходная факторизация известна (детали есть по ссылке выше).

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

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

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

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

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

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

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

Удивительно, что во многих проектах, оказывается, 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 это позволяет реализовать. Но нужно создать общий список доверенных ключей третьей стороны. Отсюда возникает инфраструктура УЦ.

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

Напишу, пожалуй, несколько общих змечаний, касающихся компрометации ключей УЦ eMudhra.

Секретные ключи ECDSA, соответствующие нескольким промежуточным сертификатам данного УЦ, оказались угадываемыми. Буквально – их можно угадать, перебрав любым простым способом менее 255 натуральных чисел. Секретный ключ в ECDSA – это обычное натуральное число. При этом открытый ключ, соответствующий угадываемому секретному, на вид ничем не отличается от стойкого ключа. Потому что открытый ключ в ECDSA это точка на кривой (P-384, в данном случае), то есть, ещё пара натуральных чисел из определённого множества.

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

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

Угадываемый ключ означает, что можно взять открытый ключ из сертификата УЦ, найти за полсекунды секретный ключ, а потом начать самостоятельно выпускать доверенные TLS-сертификаты – то есть, сертификаты, в которые будет верить обычный браузер, в том числе, Chrome или “Яндекс.Браузер”; см. ниже про Certificate Transparency (CT). (И ещё тут всё будет работать, но за некоторыми исключениями: для ряда TLS-узлов может использоваться так называемый key pinning – то есть, привязка по ключам сервера или УЦ в цепочке, но это редкие детали.)

Если у вас есть доверенный сертификат, то можно активно перехватывать TLS-соединение: подменять практически любой HTTPS-узел, потому что дополнительной привязки ключей к именам, фактически, в вебе нет (DANE не используется, HPKP – запретили, и т.д.). Но для такого перехвата нужно контролировать канал. Расшифровать чужой, “не подменённый”, трафик доверенный сертификат не позволяет. Как только что отмечено, для особо важных узлов, типа некоторых сервисов Google, может использоваться упомянутый key pinning на уровне браузера, и тогда активная подмена сессии будет обнаружена браузером (и об этом может быть автоматически заявлено в Google, например).

В современных браузерах, в общем случае, доверие TLS-сертификату требует, чтобы в сертификате были доверенные SCT-метки, которые выдают операторы CT-логов. Метки подписаны. И подписаны они другими ключами, ключами оператора лога. Эти ключи – в другой цепочке доверия, которая никак к сертификатам УЦ не привязана. Поэтому компрометация ключа УЦ “от сертификатов” не позволяет подделать SCT-метку (для этого нужен секретный ключ лога; насколько “секретны” эти ключи – другой вопрос).

Однако в процессе выпуска сертификата можно предъявить соответствующий пресертификат оператору лога и получить доверенную SCT-метку, которую уже потом добавить в сам сертификат. Операторы логов принимают все подходящие по интервалу валидности сертификаты, выпущенные в цепочке от доверенных корней. Это доверие примерно эквивалентно доверию в браузере. Соответственно, если скомпрометирован ключ такого доверенного УЦ, то можно просто штатным образом предъявлять пресертификат с валидной подписью и получать SCT-метку (да, тут не оговорены разные возможные ограничения доступа к размещению пресертификатов, но это другая история; обычно, ограничений нет – главное, чтобы было доверие корню). Таким образом, получить SCT-метки и сделать сертификат доверенным с точки зрения браузера – возможно. Но останется отметка в CT-логе (в общем случае).

Следов сертификатов от скомпрометированных ключей eMudhra в CT-логах пока выявить не удалось. Это не означает, что сертификаты не были выпущены и использованы в приложениях, которые, в отличие от браузеров, не требуют SCT-меток при валидации. Таких приложений тоже немало: это разные утилиты для работы с вебом, почтовые системы и т.д. Кто, как и где использовал такие сертификаты, если использовал, – неизвестно. И это речь шла про TLS. Хуже всего, что есть сертификаты ключей подписи кода, и доверие там выстраивается похожим способом.

Ключи eMudhra были кросс-подписаны Sectigo. Это означает, что доверие распространялось от корней УЦ Sectigo. Кросс-подпись, в смысле доверия, зависит от ключа, а не от сертификата, так что с точки зрения компрометации – лучше не делает. Почему Sectigo не проверяли стойкость ключей, которые находятся в “их цепочке доверия”? Это тоже “большая загадка”. Но, опять же, таковы реалии инфраструктуры TLS-сертификатов в вебе.

Сертификаты скомпрометированных ключей можно и нужно отозвать. Это сделано. Проблема в том, что отзыв работает плохо, а CRL (списки отзыва) мало какие клиенты проверяют. Chrome – не проверяет. Однако в браузерах типа Chrome есть инструменты исключения доверия по отпечаткам ключей, новые отпечатки – распространяются с обновлением браузера. Именно так доверие данным ключам и было “снято” на днях. Однако тривиальный секретный ключ означает, что его, этот ключ, невозможно удержать в секрете.

Почему в браузеры (например) сразу не встроены подобные тривиальные ключи как недоверенные? Причин две. Первая – мало кто верил, что угадываемый ключ может быть использован полноценным УЦ, а каждая проверка по списку – это дополнительные такты процессора в программе, реализующей TLS-стек. Вторая причина – непонятно, на каком количестве ключей нужно остановиться: 128? 256? 2^16? И каждая итерация – довольно большие затраты вычислительного ресурса.

Вот.

Занятно, кстати, что секретные ключи скомпрометированного УЦ TLS eMudhra просто оказались угадываемыми – их значения лежали в интервале от 1 до 256:

The 8 impacted keys all used integers less than 256. (Все восемь затронутых ключей являлись целыми меньше 256.)

В УЦ, естественно, сертифицированные HSM и т.д., и т.п. Бывает. Байтовый скаляр можно угадать меньше чем за секунду, HSM “по FIPS” тут не мешает.

Недавно у меня студенты МГТУ делали курсовую работу по поиску секретных скаляров для ключей ECDSA на P-256 табличным методом: ну, что ж, вот вам очередной живой пример полезности данного метода (пусть и тривиального, с точки зрения теоретической математики).

В комментарии Beldmit прислал ссылку на описание того, что скомпрометированы ключи УЦ eMudhra, который находится в списках доверенных всех распространённых браузеров. В качестве доказательства там предъявлены подписи от этих ключей. Проблема большая: это означает, что тот, у кого есть секретные ключи, мог выпускать доверенные сертификаты для произвольных имён и выполнять атаку MITM. (Да, метки логов Certificate Transparency (SCT) – тоже можно было получать на такие сертификаты, это несложно.)

Немного пояснений к предыдущей записке, о том, что в стандартную библиотеку Go crypto/x509 “гвоздями прибили” некоторые отпечатки открытых ключей, которым библиотека теперь не доверяет напрямую, минуя все прочие проверки. Причина, как бы, в том, что у некоторого УЦ утекли ключи от доверенных промежуточных сертификатов (по ссылке от Beldmit есть важные подробности). Что тут можно сказать? Основное: это максимально странная история – типичный костыль, неожиданность постановки которого только укрепляется тем, что это сделано в Go. Далее – чуть подробнее.

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

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

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

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

Нехорошая тенденция, в общем.

В стандартной библиотеке Go crypto/x509, к сожалению, тоже начали понемногу разламывать внутреннюю логику: в свежем релизе 1.27.3 добавлена функция, которая внутри библиотеки, в ветке проверки валидности цепочки сертификатов, непосредственно признаёт невалидными сертификаты по отпечаткам некоторых открытых ключей.

Нормальных объяснений – что это за ключи, почему их нужно встроить непосредственно в библиотеку, – нет. Сказано только, что это результат компрометации УЦ. Почему это должно требовать изменения логики работы verify.go, с привязкой к конкретным ключам, не объясняется. Очень странно.

Заметьте, что данный способ отбрасывания сертификатов по отпечаткам ключей работает вне зависимости от того, какой список доверенных сертификатов вы используете: ещё раз – ключи зачем-то зашили прямо в исходный код библиотеки (distrustedSPKIHashes в коде verify.go).

Какую статистику могут собирать системы Let’s Encrypt, как крупнейшего, по количеству оконечных TLS-сертификатов, удостоверяющего центра (УЦ) в Интернете? Вроде, часть статистики очевидна – имена доменов, IP-адреса, которые вносятся в сертификаты, и т.д. Но можно “загадать” и неочевидные элементы.

Начнём, впрочем, с очевидных. Понятно, что любые имена, которые УЦ вносит в сертификаты, это предмет внутренней статистики: общее количество, количество сертификатов на имя, разбивка по дереву DNS. Тут, при разбивке, не только по доменам верхнего уровня нужно делить: куча сертификатов Let’s Encrypt выпускается для технических доменов четвёртого, пятого уровня, и даже ниже (максимум – десятый, это ограничение УЦ). Сюда же относится и срок действия выпущенного сертификата: сколько коротких, сколько – обычных, как это проецируется на имена.

Менее очевидные показатели. Прежде всего, проверка права управления ресурсом (именем). Тут напрашивается подсчёт вариантов: DNS, HTTP, ALPN и т.д. Всё с разбиением по типам сертификатов, по открытым ключам. Узлы, с которых запрашиваются ACME-проверки, обозначат IP-адреса источников ACME-запросов. В рамках проверки можно обнаружить, где размещаются проверяемые ресурсы: хостинг DNS, хостинг веб, распределение IP-адресов. Причём, можно построить соответствие адресов, на которых используется сертификат (см. ниже), с адресами, которые “засветились” в процессе проверки права управления.

Важна статистика по результатам проверки: успешно, не успешно, причины отказа. Данные по CAA-записям – какие имена, где размещены сами записи (не обязательно совпадает с DNS-DCV, потому что CAA-запись может быть выше уровнем).

И, конечно, всё с разбивкой по ACME-аккаунтам. Потому что каждый ACME-аккаунт имеет собственный набор идентификаторов (ключ, номер и т.д.).

Откуда тут вообще возьмутся IP-адреса, отличные от тех, которые, – возможно, – указаны в сертификатах? Прежде всего, ACME-клиент приходит с какого-то IP-адреса. Это можно зафиксировать и привязать к ACME-аккаунту. Когда DCV-подсистема проверяет право управления, эта подсистема осуществляет опрос DNS (во всех случаях, кроме, возможно, проверки управления конкретным IP-адресом) – IP-адреса авторитативных серверов DNS разных уровней тоже можно записывать. При проверке HTTP – запросы к веб-серверу отправляются по конкретным IP-адресам; если процесс связан с DNS-проверкой, то IP-адрес берётся из DNS, если с проверкой IP-адреса, то этот адрес указывается в заказе, отправленном по ACME. Соответственно, получаем ещё адреса, пригодные для включения в статистику. И эти адреса можно привязать к сертификатам, ключам, доменным именам.

Откуда взять IP-адреса узлов, на которых используется сертификат? Для сертификата, который выпущен для IP-адреса – очевидно: из самого сертификата. Для DNS-имён – чуть менее очевидно: заказ и получение сертификата не обязаны выполняться с тех же серверов, где сертификат будет использоваться. Однако всякий уважающий себя УЦ выполняет, при помощи специального бота, обход узлов, имена которых указаны в выпущенных сертификатах, как раз для того, чтобы вести статистику использования. Из этого процесса и возьмутся IP-адреса носителей. Если, конечно, соответствующие узлы доступны для бота.

Некоторую статистику можно было бы видеть по OCSP-респондерам, но их в Let’s Encrypt больше нет. Из действующих схем проверки статуса сертификата остаются списки отзыва (CRL). Соответственно, можно строить статистику запросов к точкам раздачи этих списков – с каких IP-адресов и какие именно CRL-файлы запрашивают. Ещё есть точки раздачи промежуточных и корневых сертификатов УЦ. Опять же, запросы к ним – дополнительный источник статистики.

Почему-то свежую (относительно) уязвимость в ядре 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-записью уже вызовет “панику” ядра. Что, конечно, тоже немало.

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

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