Кратко

  • Четыре руководства по TLS дали от 14% до 80% несоответствий, когда их применили к одним и тем же 50,7 млн сообщений Server Hello, собранных в одной организации за 14 дней.
  • В выборке было 6,85 млн рукопожатий с X25519MLKEM768 — гибридной постквантовой группой, которую не упоминало ни одно из четырёх руководств. «Не указано» не означает «взломано».
  • TLSGatekeeper умеет наблюдать за отдельными параметрами рукопожатия и при желании блокировать соединение без расшифровки прикладного трафика. Показатель 100 Гбит/с получен в лаборатории при отключённой блокировке, а не подтверждён производственным развёртыванием.

Одна связь, разные правила

Цифра «80% не соответствуют требованиям» на панели безопасности выглядит характеристикой сети. В этом исследовании она также отражает выбранный свод правил, по которому сеть оценивали.

Гостевая публикация в блоге APNIC рассказывает о работе Henrique Becker Brum и коллег из Университета Тренто и Fondazione Bruno Kessler. Статья arXiv:2605.31020v1 сопоставляет двухнедельную выборку с четырьмя национальными рекомендациями по кибербезопасности: итальянской ACN, французской ANSSI, немецкой BSI и американской NIST. По трём измеренным параметрам доля несоответствий составила примерно 14% для ANSSI и 80% для NIST.

При смене руководства соединение не меняется; меняется его метка. Если организация автоматически блокирует трафик по этой метке, толкование документа начинает определять, какие соединения доступны пользователям.

Рекомендации не бесполезны и не обязательно произвольны. Они рассчитаны на разные государственные среды, модели угроз и сценарии перехода. Проблема возникает, когда система смешивает три состояния: известную слабость, прямой запрет и значение, которое ещё не оценивалось. Объединить всё под названием «несоответствие» удобно для автоматизации, но трудно для объяснения.

Что именно измерили авторы

Сбор проходил с 13 по 26 октября 2025 года на трафике из внутренней сети Fondazione Bruno Kessler к внешним серверам. После очистки авторы насчитали 155 066 707 пакетов. Базой для оценки выбранных сервером версии TLS, набора шифров и группы стали 50 744 009 сообщений Server Hello.

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

Исследование проверяет три выбранных сервером значения последовательно: версию, набор шифров, затем группу. Если первое поле не соответствует выбранному руководству, последующие не учитываются как причина несоответствия этой записи. Работа не проверяет все настройки каждого сервера, его сертификаты, программное обеспечение, среду эксплуатации или поведение после рукопожатия. Поэтому «соответствие» здесь означает лишь сравнение некоторых наблюдаемых параметров с заданными правилами, а не полную сертификацию безопасности конечной системы.

Этого ограничения достаточно, чтобы увидеть эксплуатационную проблему: в четырёх документах нет универсального словаря приемлемых параметров.

«Не указано» — отдельное состояние

Наиболее показательный пример — X25519MLKEM768. Набор данных содержит 6 845 778 сообщений Server Hello, в которых сервер выбрал эту группу, — примерно 13,5% выборки. В таблице авторов она указана среди значений, приводивших к несоответствию, хотя ни одно из четырёх руководств её не упоминало.

Название соединяет широко применяемую классическую группу X25519 с ML-KEM — постквантовым механизмом инкапсуляции ключей, стандартизованным NIST в FIPS 203. Это не означает, что каждое соединение стало «квантово-стойким». Измерение подтверждает выбор сервером гибридной группы в этой выборке, но не безопасность всего сеанса, клиентскую реализацию или завершённый переход на криптографию после квантовой эры. Не следует также смешивать эту группу с более ранним черновым значением X25519Kyber768_Draft00, которое рассматривается отдельно.

Практический вывод точнее лозунга «постквантовая криптография уже здесь». Устаревший список совместимости может признать несоответствующим значение, уже встречающееся в реальном трафике, хотя авторы не указывают на известную уязвимость этого значения. Руководство встретило то, чего пока не описывает его словарь. Это повод пересмотреть правило, но не доказательство того, что значение нужно блокировать.

Есть и обратная сторона. Авторы отмечают, что Curve25519 широко применяется и принимается ведущими браузерами, но не одобрена в проверявшейся рекомендации NIST. ChaCha20-Poly1305 — современный алгоритм шифрования, который NIST не рекомендует. Это не призыв игнорировать публичные требования. Это напоминание: «не соответствует этой базовой линии» и «криптографически сломано» — разные утверждения с разными доказательствами и последствиями.

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

От наблюдения к блокировке

TLSGatekeeper — сетевой посредник на основе XDP/eBPF. Он читает выбранные поля в сообщениях Server Hello или Server Key Exchange, сравнивает их с политикой, записывает результат и при необходимости блокирует соединение. Содержимое приложения он не расшифровывает. Поскольку инструмент анализирует параметры, выбранные сервером, Encrypted Client Hello скрывает клиентский SNI, но не закрывает от него именно те серверные поля, которые он проверяет.

Контроль переносится с отдельных браузеров и приложений на сетевой выход. Организация может применить правило сразу ко многим клиентам, не настраивая каждое устройство; это полезно для временных или напрямую не управляемых устройств. Но такая концентрация создаёт общую точку отказа: ошибочное правило, ограничение парсера или непроверенное обновление затронет всех, кто проходит через посредника.

В испытании производительности использовались два модуля BlueField-2, соединённые со скоростью 100 Гбит/с внутри одного сервера. При шестнадцати фоновых потоках канал приближался к пределу устройств. Авторы сообщают среднюю задержку проверки 671 наносекунду для пакетов рукопожатия TLS 1.3 и 795 наносекунд для TLS 1.2.

Это лабораторные измерения обработки пакетов, а не гарантия линейной скорости для любой архитектуры и любого трафика. Важнее то, что в тесте блокировка была выключена. Пакеты продолжали путь в сетевой стек хоста через XDP_PASS. Результат показывает низкую измеренную задержку проверки в заданной конфигурации, но не доказывает надёжность активной блокировки в производстве, правильность конкретной политики или наличие развёрнутых клиентов.

У реализации есть чёткие границы: традиционный TLS поверх TCP, но не QUIC и не DTLS. Оператору нужно знать, какие маршруты обходят проверку. «Не расшифровывает» — значимое свойство приватности, но не отсутствие контроля: посредник может заменить пакет рукопожатия на TLS Alert и не дать соединению установиться.

APNIC публикует исследование, но не выполняет его

Блог APNIC — открытая техническая площадка для сообщества Азиатско-Тихоокеанского региона. Гостевая публикация не свидетельствует о том, что APNIC разработала, испытала или внедрила TLSGatekeeper. Принадлежность авторов к исследовательским организациям и оговорка гостевой публикации отделяют работу от деятельности самого регистра.

Операторам региона важно не выяснять, какое государственное руководство «победило», а понять, как локальная норма становится сетевым действием. Ведомство может предписать конкретный профиль для определённой государственной службы; университет — выбрать иной базовый профиль для управляемых устройств; сетевой команде может потребоваться временно разрешить новый обмен ключами на время проверки. Такие решения совместимы, если система фиксирует применимый источник полномочий, область действия, протокол и редакцию документа.

Лишённый контекста список плохо переносится между средами. Значение, разрешённое в одном профиле, может быть запрещено в другом. После обновления руководства неизменившееся соединение может внезапно получить метку несоответствия. Если журнал хранит лишь «заблокировано: несоответствие», расследование может не восстановить сработавшее правило и не отличить запрет от отсутствия оценки или упоминания.

Надёжная запись должна хранить проверявшееся поле, наблюдаемое значение, идентификатор и редакцию руководства, причину отказа, время и путь к исключению или исправлению. Иначе исполнение будет детерминированным, а основания управления — непрозрачными.

Как безопаснее перевести руководство в действие

Один из разумных вариантов — кодировать три состояния: разрешено, запрещено и не оценено. Для известных уязвимостей нужна отдельная техническая аргументация. Состояние «не оценено» должно становиться видимым и запускать проверку, а не молча наследовать поведение «запрещено».

Если блокировка обязательна, новое правило можно сначала включить в режиме наблюдения. Оператор измеряет, какие соединения оно затронет, определяет службы, испытывает правило на ограниченном сегменте и лишь затем расширяет охват. У правила должны быть источник, дата, ответственный и срок пересмотра. Исключениям нужны утверждающий и дата окончания; путь отката следует проверить до масштабирования.

Это редакционные рекомендации, а не функции, которые авторы приписывают TLSGatekeeper. Они следуют из разрыва между сравнением с документом и действием над пакетом. Авторы политики контролируют формулировки, сетевые операторы — локальное применение, сопровождающие ПО — поведение парсера, а пользователи — последствия разрыва. Запись решения должна сохранять эти границы ответственности, а не изображать посредника носителем универсальной истины под названием «соответствие».

Note 64 Хенга Лу даёт полезную перспективу проектирования: общий технический базис не должен превращать каждый будущий выбор в запрос централизованного разрешения. Это не означает игнорирование публичных правил. Это означает точное определение их области и локальную оценку последствий оператором. Особенно важно это тогда, когда наиболее заметная «ошибка» — криптографическое значение, за которым руководство ещё не успело.

Что позволяют утверждать данные

Исследователи показывают, что в крупной выборке одной организации присутствовали новые и старые TLS-значения, оценки различались между руководствами, а сетевой посредник смог проверять выбранные поля при высокой лабораторной пропускной способности. Работа не показывает, как часто организации блокируют значения в производстве, какой ущерб это наносит пользователям, насколько выборка представляет Интернет или что гибридная группа означает для сквозной безопасности.

Эти пробелы не обесценивают исследование. Они отделяют полезное измерение от неподтверждённого утверждения о внедрении. Самый надёжный вывод — не «80% TLS небезопасно», а то, что одни и те же наблюдаемые соединения получают очень разные оценки по четырём авторитетным наборам правил и что оператор может превратить эти расхождения в решение на уровне сети.

Когда руководство говорит «не указано», обработчик пакетов не должен выдумывать недостающий мотив. Кто-то должен решить, запрещено ли значение, не оценено или разрешено более новой локальной политикой. Решение должно быть видимым, пересматриваемым и обратимым. Иначе список разрешений не просто исполняет рекомендации по безопасности — он незаметно сам становится политикой безопасности.

Источники