Кратко

  • В материале LACNIC с номером 4984 видны два полных URL в /rpki/, но href хранит два пути /innovaportal/file/4983/1/.
  • 30 августа оба видимых адреса ответили HTTP 200, типом text/html, длиной 7 014 байт и одинаковым SHA-256. Цели кликов вернули два разных TAL длиной 502 и 518 байт.
  • Каждый TAL указывает на отдельный сертификат, и оба сертификата удалось получить. Это ограничивает вывод уровнем публикации и не доказывает отказ валидатора, репозитория, ключа, ROA или маршрута.
  • В квитанции выпуска следует соединить видимую надпись, разрешённый href, тип ответа, грамматику TAL, хеш, сертификат и историю исправлений.

Один элемент страницы содержит две инструкции

Страница RPKI Trust Anchors - TAL описывает обычный TAL LACNIC и отдельный TAL для политики AS0, а затем предлагает скачать файлы. На экране указаны пути /rpki/lacnic.tal и /rpki/lacnic-as0.tal на публичном хосте LACNIC.

В записи CMS 4984 первым текстом управляет href /innovaportal/file/4983/1/lacnic.tal, вторым — /innovaportal/file/4983/1/lacnic-as0.tal. Публичная конфигурация интерфейса задаёт базу innova.lacnic.net/innovaportal.

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

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

Два ответа 200 не стали двумя документами TAL

30 августа 2026 года в 04:48 UTC обычный видимый URL и видимый URL AS0 были запрошены без кеша. Оба ответили 200 с типом text/html.

Каждый ответ содержал 7 014 байт, а SHA-256 совпал: 7a17eab5484db68fe84e396d8fb7b6326cfff37d10c7467c0296655a899dc416. Совпало и время Last-Modified — 28 августа, 13:20:15 GMT. Это одна HTML-оболочка нового приложения LACNIC.

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

Зато оно отделяет доступность хоста от доступности артефакта. Мониторинг статуса и задержки назовёт оба запроса успешными. Проверка структуры TAL остановится, не найдя ожидаемого набора URI, пустой строки и открытого ключа.

По целям ссылок сохранились два разных файла

Обычная цель Innovaportal вернула application/aux, 502 байта и SHA-256 d44bb9394ab009c8b53e5efebf2a1c9450bab61a27efe00de5a3e4587a3a2f6a. В ней указаны HTTPS- и rsync-адреса обычного сертификата и материал открытого ключа.

Цель AS0 вернула 518 байт и SHA-256 671a1b78c51ac023e7500212f0039699e94f4143eab05260284eccc3858e9eff. Путь репозитория, сертификат и ключ отличаются.

Обычный сертификат длиной 1 166 байт и сертификат AS0 длиной 1 160 байт тоже были доступны. Это разные бинарные объекты.

Такая проверка не подтверждает всё состояние RPKI LACNIC. Её задача — не позволить ошибке в отображаемом URL превратиться в неподтверждённый рассказ об отказе репозитория. Страница также говорит, что большинство инструментов уже включает необходимые TAL. Масштаб воздействия неизвестен и не должен додумываться.

Формат задаёт проверяемую цепочку

Согласно RFC 8630, TAL содержит один или несколько упорядоченных URI сертификата, пустую строку и SubjectPublicKeyInfo якоря в Base64. Затем полагающаяся сторона загружает актуальный самоподписанный сертификат CA RPKI и сравнивает ключ.

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

Веб-страница добавляет нулевой шаг: совпадает ли текст для копирования с целью действия. Различие допустимо для редиректа или сервиса загрузки, но тогда оно должно быть частью публичного контракта. У bootstrap-материала URL неизбежно покидает браузер и становится операционными данными.

Самое доброжелательное объяснение остаётся достаточным

Набор фактов похож на неполную состыковку нового интерфейса со старой публикацией файлов. Пути /rpki/ попадают в общее приложение, а href в CMS продолжает выдавать артефакты. Сами TAL и названные сертификаты не исчезли.

LACNIC может исправить подписи либо сделать видимые адреса настоящими алиасами с выдачей или перенаправлением. Важен не выбор внутренней архитектуры, а одинаковый результат для клика, копии и автоматического запроса.

Молчаливое изменение поможет будущим обращениям, но лишит старые измерения объяснения. Короткая запись об исправлении или версионная квитанция сохранит прежний хеш страницы, пары URL, время и новый канонический статус.

Проверять нужно всю строку загрузки

Квитанция для каждого элемента должна включать версию страницы, видимый текст, исходный href, абсолютную цель, роль обычного TAL или AS0, ожидаемый тип и статус алиаса. Зонд обращается и к надписи, и к цели.

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

История дописывается, а не заменяется: момент обнаружения, предыдущая версия, категория причины, новый адрес и поддерживаемые старые имена. Исправление становится проверяемым и не стирает прошлое.

Во время наблюдения клики работали. Напечатанные URL тоже отвечали. Но они выдавали не тот класс объекта, который обещала подпись. Поэтому доступность и идентичность нельзя объединять в один зелёный индикатор.

Источники