Электронная почта существует с 7-х годов, шифрование в ней появилось ещё в 90-х, однако заголовки писем всё это время оставались открытыми, так что их можно было менять, как угодно, и это никого особенно не смущало. Получалось забавно: вы упаковывали тело письма в криптографический кокон, но при этом любой MITM мог переписать Subject с «Re: квартальный отчёт» на «Re: срочный платёж», а клиент почты делал вид, будто так и было. И лишь в 2025-м IETF решило, что, возможно, стоит защищать не только содержимое, но и шапку письма.
Что происходило раньше
Попытка решить проблему уже была: стандарт RFC 8551HP предлагал складывать заголовки внутрь message/rfc822 вложения, что выглядело как костыль, который формально работает, но в реальности ломает половину клиентов. Письма оказывались «прикреплёнными файлами», подписи терялись, а пользователи удивлялись, почему интерфейс показывает что-то странное. Наружные заголовки оставались на виду, поэтому именно их атакующие и меняли, пользуясь тем, что система позволяла это делать безнаказанно.
Что придумали теперь
Идея RFC 9788 выглядит почти обидно простой: заголовки копируются внутрь зашифрованной или подписанной части, а наружу выносится только минимальный набор — например, Date или To. Если требуется, Subject заменяется на скромное […]. Для дедушкиных Outlook 2003 предусмотрен «Legacy Display», который современные клиенты должны скрывать, иначе защита превращается в декорацию.
В результате любое вмешательство в тему или отправителя фиксируется сразу: клиент сравнит наружные данные с защищёнными внутренними и покажет расхождение. Та самая банальная атака «подменим тему в пути» теряет смысл.
Почему бизнесу это выгодно
Парадокс: компании тратят миллионы на антифрод, SOC и DLP, но десятилетиями принимали письма, в которых отправитель и тема могли быть переписаны на лету. Это примерно как ставить дорогую сигнализацию в машину, но оставлять ключи под ковриком.
Теперь с RFC 9788 появляются ощутимые бонусы: снижается число успешных фишинговых атак, а вместе с ними и прямые финансовые потери; уменьшается нагрузка на SOC, ведь ложных срабатываний становится меньше; партнёры начинают быстрее заключать сделки, потому что уверены в подлинности переписки; регуляторы и юристы получают аутентичные письма, а значит — меньше рисков по комплаенсу.
Как это будет разворачиваться
Никто не ждёт, что переход произойдёт мгновенно: сперва поддержку внедрят энтузиасты и open-source клиенты, затем корпоративные решения начнут «тихие релизы» с Header Protection, а массовое распространение займёт от двух до пяти лет, как это было с HTTPS. На старте будет использоваться политика hcp_baseline, которая прячет самое чувствительное (например, тему), но оставляет минимум наружных полей для совместимости; позже появятся более строгие режимы.
Если вы делаете почтовый клиент и решили пока отложить внедрение RFC 9788, — через пару лет пользователи будут смотреть на ваш продукт так же, как мы сейчас смотрим на сайты без HTTPS — с вопросом «а вы вообще серьёзно?».
И смешнее всего то, что эта очевидная дыра существовала десятилетиями. Мы умудрялись защищать тело писем, но позволяли переписывать заголовки вручную. Теперь это наконец закрыли — поздно, но всё же лучше, чем никогда.
Ссылки, как обычно, в моём канале
——————Менеджер? Давай сюда!Ищи работу здесьТехнологии и архитектура
Источник: habr.com