Кратко

  • Content-Digest сверяет фактическое содержимое сообщения, а Repr-Digest — полные данные выбранного представления. Совпадение не устанавливает, кто выбрал эти байты.
  • Надёжный журнал разделяет область байтов, алгоритм, перерасчёт, охват подписи, полномочия ключа, время, повтор, деловую проверку и окончательное действие.

Зелёный индикатор сообщил слишком мало

Пересчитанное значение действительно совпало с полем. Ошибкой стал следующий вывод: будто из этого следует право применить файл.

Тому, кто управляет и телом, и дайджестом, не нужно атаковать SHA-256. Он вычисляет хеш собственного вредоносного содержимого. Получатель повторяет расчёт и закономерно получает то же значение. Доказано соответствие двух входов, а не надёжность их источника.

Поэтому verified=true непригодно для серьёзного решения. Нужны отдельные результаты: content_digest_matched, signature_verified, key_authorized, replay_rejected. Название предиката удерживает доказательство в его настоящих границах.

Сначала выбирают область байтов

RFC 9530 определяет Content-Digest для фактического содержимого HTTP-сообщения, а Repr-Digest — для всех данных выбранного представления. Кодирование содержимого, диапазоны, методы и метаданные представления способны развести эти области.

Шлюз может проверить сжатые байты, тогда как приложение полагает, что проверено распакованное представление. Оба компонента могут говорить правду о разных объектах. Поэтому до выбора SHA-256 или SHA-512 нужно назвать инвариант: какие байты и на какой стороне преобразования обязаны оставаться неизменными?

Отмена RFC 3230 показывает цену неточности. Термин «instance» трактовали по-разному, особенно смешивая содержимое сообщения и данные представления. Новые имена помогают лишь тогда, когда их различие сохраняют журналы и испытания.

Правильный словарь не является удостоверением

Оба поля — словари Structured Fields. Ключ обозначает алгоритм, значение переносит последовательность байтов дайджеста. Несколько алгоритмов могут облегчать переход.

Успешный разбор не означает принятие. Получателю нужны список разрешённых алгоритмов, правило для нескольких значений и явное завершение при ошибке. Реестр IANA сообщает статус; RFC 9530 рекомендует активные алгоритмы для многих случаев и запрещает устаревшие там, где возможен противник.

Base64 только кодирует байты. Кодирование, хеширование и подпись — разные операции. Поля Want-Content-Digest и Want-Repr-Digest тоже не создают обязанности: это пожелания, которые допустимо игнорировать. Обязательное требование должно принадлежать политике приложения.

Подпись поля не отменяет пересчёт тела

HTTP Message Signatures может охватить Content-Digest, метод, цель и другие выбранные компоненты. Тогда объявленное значение связывается с проверенным ключом.

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

Допустим, дефект заменил тело, но сохранил подписанное поле. Подпись может остаться действительной: само поле не менялось. Только независимый пересчёт обнаружит несовпадение. И наоборот, один пересчёт без подписи позволяет неизвестному лицу прислать новое тело и подходящее значение.

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

Трейлер переносит момент решения

RFC 9530 разрешает поле в заголовке или трейлере. При потоковой передаче отправитель может узнать дайджест только в конце. Значит, и получатель получит полное доказательство лишь после тела.

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

HTTP/1.1, HTTP/2 и HTTP/3 переносят трейлеры по-разному. Посредники и фреймворки могут удалять или иначе показывать их. Только испытание всего производственного пути доказывает, что решающий компонент видит поле до фиксации.

Целые байты всё равно могут устареть

Объект в кеше способен сохранить прежние байты и правильный дайджест, хотя его свежесть закончилась. RFC 9111 отдельно определяет свежесть, повторную проверку и использование устаревшего ответа.

Подписанный запрос также можно повторить без изменений. Тело, дайджест и подпись снова пройдут контроль. Временное окно, nonce, идентификатор запроса и идемпотентность решают, допустимо ли второе выполнение.

Смысл тоже проверяется отдельно. Формально верная конфигурация может выдать опасные права. Пакет может совпасть с дайджестом издателя и содержать уязвимый код. Целостность сохраняет предъявленный объект, но не одобряет его последствия.

Отрицательные испытания задают предел

Сначала отправьте вредоносное содержимое с правильным дайджестом. Контроль целостности должен пройти, а авторизация — отвергнуть действие. Затем измените один байт при прежнем дайджесте и потребуйте отказ до изменения состояния.

Подпишите запрос без Content-Digest, затем включите поле в подпись, но измените тело. Проверьте несколько алгоритмов, включая неизвестный и устаревший, чтобы порядок не вызвал снижение защиты. Пройдите сжатие, диапазоны и реконструкцию представления.

Наконец, проведите трейлер через каждую версию HTTP и каждого посредника, повторите действительный запрос и выдайте устаревший кеш с совпадающим дайджестом. Каждый барьер должен отвечать только на свой вопрос.