Кратко

  • HP-Outer сохраняет внутри зашифрованной нагрузки защищённую запись о заголовках, которые составитель намеренно оставил снаружи; это квитанция о составлении, а не наблюдение за всей доставкой.
  • Фактический криптографический статус определяется полученными MIME-слоями, тогда как параметр hp сообщает о намерении и не может заменить отсутствующее шифрование.
  • Внутренний и внешний From, подпись и её привязка, транспортная аутентификация, показанное имя и адрес ответа являются разными решениями с разными доказательствами.

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

RFC 9787 использует этот пример, чтобы показать цену потерянной семантики. RFC 9788 добавляет ещё одну размерность: даже корректный статус всего сообщения не отвечает, какие конкретно заголовки были конфиденциальны, что автор оставил наружу и какой адрес имеет право управлять ответом.

Свести всё к одному флагу удобно. Восстановить после этого причинную цепь невозможно.

Криптографический статус расположен в MIME-дереве

RFC 9787 описывает S/MIME и PGP/MIME как криптографические слои в структуре MIME. Слой подписи даёт целостность и подлинность в пределах результата проверки. Слой шифрования даёт конфиденциальность, а свойства целостности зависят от формы. Порядок существенен: «подписать, затем зашифровать» и «зашифровать, затем подписать» создают разные утверждения.

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

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

Старая схема RFC 8551 помещала полный объект message/rfc822 в криптографический конверт. Наследуемые MUA обнаружили проблемы отображения и безопасности. RFC 9788 заменяет эту конструкцию: известные составителю заголовки копируются прямо в защищённую нагрузку. В шифрованном письме неструктурный заголовок можно сохранить снаружи, заменить маской или удалить.

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

HP-Outer фиксирует решение автора

Новое поле HP-Outer располагается в заголовках шифрованной нагрузки. Для каждого неструктурного поля, сознательно выставленного наружу, составитель должен записать защищённую копию имени и внешнего значения.

Если внешний Subject заменён на [...], квитанция хранит эту маску. Если Date оставлен без изменений, записывается открытая дата. Если защищённое поле не имеет соответствующего HP-Outer, составитель утверждает, что при передаче в почтовую систему не помещал наружу ни одного такого поля.

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

Но запись не даёт удалению переписать прошлое. Пусть автор оставил Cc открытым и также поместил копию внутрь. Посредник удаляет внешний Cc. Наивное сравнение финального состояния объявит внутреннее поле зашифрованным. Совпадающий HP-Outer показывает, что составитель его раскрыл.

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

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

Политика — функция, а не передаваемое имя

Header Confidentiality Policy, HCP, принимает имя и значение неструктурного заголовка. Она возвращает исходное значение, маску или null, означающий удаление снаружи.

Рекомендуемая hcp_baseline минимальна: заменяет Subject на [...], убирает Comments и Keywords, остальные поля пропускает. hcp_shy дополнительно удаляет отображаемые имена из From, To и Cc и переводит Date в UTC. Это скрывает больше читаемых метаданных, но требует более сложного разбора и несёт риск доставки и отображения, поэтому не рекомендуется по умолчанию.

Имя HCP по сети не передаётся. Получатель видит решения через HP-Outer. Реестр IANA хранит стабильные реализуемые описания и отметку рекомендации. Он не свидетельствует о поддержке продуктом, настройке аккаунта или применении к конкретному письму.

Общий слой остаётся тонким: синтаксис, воспроизводимая функция и правила регистрации. Среда может скрыть To, Cc, References или In-Reply-To, но фильтры, цепочки обсуждения, списки и диагностика могут зависеть от них. Более строгая приватность требует локального эксплуатационного доказательства.

hp сообщает, что планировалось

Параметр hp защищённого Content-Type описывает намерение. cipher означает попытку шифрованной защиты заголовков; clear — вариант только с подписью. Реальный статус выводится из полученных слоёв.

Письмо только с подписью, но с hp=cipher, всё равно не конфиденциально. Клиенту запрещено повышать оценку по заявлению. Возможен и обратный случай: посредник оборачивает шифрованием письмо, которое автор создал только подписанным. Шифрованный слой у получателя реален, но его происхождение иное.

При расхождении отсутствие HP-Outer не доказывает, что исходный автор спрятал все поля. Для аудита нужны MIME-дерево, порядок слоёв, hp, все записи HP-Outer, фактически полученные внешние заголовки и решение парсера. Булево encrypted уничтожает происхождение.

Отображение и ответ используют разные полномочия

Внешний From доступен проверкам транспортного уровня. Внутренний From может быть защищён сквозной подписью. RFC 9788 определяет несовпадение как разные addr-spec этих полей.

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

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

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

Это не противоречие. Отображение ограничивает ложное авторство, а адресация ответа — захват маршрута. Читаемое имя ещё слабее: оно не глобально уникально и не обязательно входит в проверенную связь сертификата с адресом.

У приватности есть адресат

Одинаковый заголовок внутри и снаружи не скрыт от транспортных агентов. Удалённое наружное поле всё равно видят все назначенные получатели. Ключевые идентификаторы, SMTP-конверт, Received, размер и время помогают делать выводы.

Автор может сам зашифровать нежелательную утечку: версию клиента в User-Agent, имя узла в Message-ID или Bcc в неправильной копии. Шифрование надёжно доставляет эту ошибку.

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

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

Источники

  1. RFC 9788 — Header Protection for Cryptographically Protected Email
  2. RFC 9787 — Guidance on End-to-End Email Security
  3. RFC 8551 — S/MIME 4.0 Message Specification
  4. RFC 5322 — Internet Message Format
  5. RFC 3156 — MIME Security with OpenPGP
  6. RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance
  7. IANA — Mail Header Confidentiality Policies
  8. IANA — Message Headers
  9. Heng Lu — Приоритет работающего кода
  10. Heng Lu — Минимальная начальная спецификация и локальное будущее решение
  11. Heng Lu — Слои реальности и символическая власть