Кратко

  • wolfSSL 5.9.2 сообщил об уязвимости высокой серьёзности в сборках с RPK: несогласованный Raw Public Key мог занять место X.509 и обойти проверку цепочки. Исправление считает X.509 ожидаемым по умолчанию и отклоняет несовпадение формы с выбранным типом.
  • RFC 7250 определяет RPK как самостоятельный, явно согласуемый тип TLS с одной DER-структурой SubjectPublicKeyInfo. Подпись доказывает владение закрытым ключом, но SPKI не несёт подписанного имени, издателя, срока, расширений или прикладной роли.
  • Безопасное принятие требует двух доказательств: что стороны действительно выбрали RPK и что актуальный внешний реестр по-прежнему связывает SPKI с нужным узлом, сервисом, устройством или ролью. Успешное соединение не заменяет ни одно из них.

Парсер получил власть, которой у него не было

В примечаниях к версии 5.9.2 CVE-2026-55960 отмечена как High. При включённом HAVE_RPK библиотека могла принять сырой ключ без предварительного согласования этого типа. У RPK нет X.509-цепочки, поэтому соответствующая ветвь разбора не выполняла проверку доверия, ожидаемую для сертификата.

Область воздействия ограничена: отдельная сборка по умолчанию не включает RPK, но --enable-all включает. Источники не называют число атак, развёртываний или полный диапазон версий. Нельзя их додумывать. Подтверждён другой факт: форма присланного объекта смогла после handshake выбрать иной режим проверки.

Исправление вернуло правильный порядок. Если альтернатива явно не согласована, ожидается X.509. Клиент сопоставляет фактическую форму серверного credential с выбранной, сервер делает то же для клиента. Различие, включая несогласованный RPK, завершается UNSUPPORTED_CERTIFICATE. PR 10702 добавляет двусторонние регрессионные тесты.

Это изменение полномочий, а не только синтаксиса. Умение разобрать SPKI не даёт библиотеке права принять её. Сначала handshake выбирает контракт доверия, затем только разрешённая форма поступает в соответствующую проверку.

Что сохраняется в Raw Public Key

RFC 7250 регистрирует Raw Public Key как CertificateType 2 и вводит расширения для типов клиента и сервера. Конечные точки сообщают, что способны выдавать или обрабатывать, после чего выбирается общий вариант. Если общего нет, тихая автоподмена недопустима.

В режиме RPK сообщение Certificate содержит одну DER-кодированную SubjectPublicKeyInfo: идентификатор алгоритма, параметры и биты ключа. Та же структура вложена в X.509, но остальная подписанная оболочка отсутствует.

RFC 8446 переносит модель в TLS 1.3 через RawPublicKey(2) и разрешает после согласования не более одной SPKI-записи. Одновременно он задаёт исходное правило: тип должен быть X.509v3, если явно не согласовано иное.

Поэтому отсутствие цепочки корректно в выбранном RPK-пути. Но синтаксически правильная SPKI не становится заменой X.509 там, где её не выбирали. Возможность чтения и право принятия — разные проверки.

Владение ключом не называет машину

CertificateVerify связывает подпись с transcript и доказывает контроль соответствующего закрытого ключа; Finished подтверждает состояние handshake. Это сильный ответ на узкий вопрос о владении.

Имя и роль из него не следуют. RFC 5280 показывает, что убрано: подпись CA удостоверяет связь ключевого материала с субъектом, а подписанное тело содержит издателя, субъект, серийный номер, период действия и расширения. Полагающаяся сторона всё равно проверяет путь, имя и политику; X.509 не выдаёт бизнес-права автоматически. Но в голой SPKI этих подписанных утверждений вообще нет.

Поэтому RFC 7250 требует внешне связать ключ с предъявляющей его сущностью и проверять состояние связи. Производственный fingerprint, TLSA или запись первого контакта могли быть верны раньше. Ротация, компрометация, переназначение и вывод из эксплуатации меняют ответ.

Внешний реестр должен содержать идентичность и роль, область host/service, точную SPKI, владельца решения, время начала и конца, предшественника и преемника, состояние отзыва, канал доставки и доказательство отказа от старого ключа.

API обозначают точку исполнения, но не источник доверия

wolfSSL требует включить RPK, задать допустимые типы и предоставить callback для внешней аутентификации ключа. Пример TLS 1.3 с GnuTLS устанавливает соединение, но сообщает, что peer не проверен, пока приложение не выполнит эту работу. Совместимость протокола и принятая идентичность — разные итоги.

GnuTLS умеет проверять сохранённый ключ по host и service, различает отсутствие записи и несовпадение, поддерживает срок и собственный backend. Документация предупреждает: обычная проверка сертификата не аутентифицирует RPK без тела сертификата; нужен внешний источник или правило непрерывности вроде TOFU.

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

DANE и прошивка работают на разных часах

DANE может быть внешним источником. RFC 6698 задаёт защищённые DNSSEC записи TLSA, способные выбирать SPKI и сопоставлять её полностью или по digest. Имя сервиса связывается с ключом в домене DNS-доверия.

Но клиент должен проверить DNSSEC, правильно понять usage, selector и matching type и сравнить нужный объект. Публикация без выполняющего проверку клиента не имеет силы принятия.

RFC 7671 описывает ротацию как последовательность: заранее опубликовать новую связь, дождаться истечения старых cache, развернуть ключ или сертификат и лишь затем убрать старые записи. В переходе разные проверяющие могут видеть разные допустимые поколения.

Для ограниченных устройств часы задаёт firmware. RFC 7925 предусматривает предварительную доставку ключа сервера или его hash и рассматривает RPK как способ получить криптографию с открытым ключом без полного сертификатного бремени. Долгоживущее устройство всё равно нуждается в защищённом обновлении. Экономия handshake переносит lifecycle наружу.

Семь фактов вместо одного зелёного статуса

Отделяйте настроенную политику, предложенные типы, выбор, полученную форму, доказательство владения, источник/версию/свежесть внешней связи и конкретное прикладное решение.

tls_success может скрывать несогласованный RPK, устаревшую запись, невызванный callback или слишком широкую роль. Отказ корректному ключу, наоборот, может быть безопасным результатом при неверном типе или снятой связи.

Примат исполняемого кода Heng Lu помогает расположить доказательства. RFC задаёт смысл, IANA номер, DNS или конфигурация публикуют связь. Реальная власть находится в процессе, который отвергает форму, проверяет текущую запись и ограничивает действие. Патч wolfSSL восстановил именно это вето.

Границы доказательств

Источники подтверждают характер дефекта, условие сборки и исправление. Они не подтверждают эксплуатацию, число систем или полный интервал версий. Из них также не следует общая слабость RPK по сравнению с X.509.

Явно согласованный RPK с защищённой актуальной привязкой уместен в контролируемой среде. X.509 тоже ломается при неверной проверке. Недопустимо другое: одна форма наследует принятие другой, избегая её обязательных правил.

Sources