Шифрование почты: что реально защищено

MAATRIX

«У нас вся почта шифруется» — фраза, которая звучит убедительно и почти всегда означает совсем не то, что человек имеет в виду. Обычно она значит «у нас настроен TLS между серверами», а не «содержимое письма недоступно никому, кроме отправителя и получателя». Разница между этими двумя утверждениями — это разница между реальной защитой в дороге и иллюзией защиты от всех. Разберём по фактам, что именно шифрует каждый вид шифрования почты и где заканчивается его зона ответственности.

Два разных шифрования, которые смешивают в кучу

Когда говорят «зашифрованная почта», обычно имеют в виду одну из двух совершенно разных вещей, и путаница между ними — источник почти всех завышенных ожиданий.

Первое — это шифрование соединения между почтовыми серверами: TLS (в почте чаще всего в виде STARTTLS поверх SMTP, реже implicit TLS/SMTPS на порту 465). Это транспортный уровень: защищается канал связи, а не сам объект, который по нему передаётся.

Второе — это шифрование содержимого письма: PGP/GPG или S/MIME. Здесь шифруется само тело письма (иногда и вложения) ещё до отправки, и расшифровать его может только обладатель приватного ключа получателя — независимо от того, сколько серверов письмо прошло по дороге.

Это не конкурирующие технологии и не взаимозаменяемые опции «выберите один вариант». Они решают разные задачи и обычно работают (или не работают) одновременно, независимо друг от друга. Именно поэтому у вас может быть идеально настроенный TLS и при этом ноль защиты содержимого письма от промежуточного сервера — или наоборот, PGP-шифрованное письмо, у которого тема и адреса видны любому по пути.

TLS: шифрует канал между конкретными серверами, не письмо целиком

STARTTLS в SMTP работает так: сервер А устанавливает соединение с сервером Б, они договариваются перейти на шифрованный канал (handshake — отдельная большая тема, там же согласуются алгоритмы и проверяются сертификаты), и дальше весь трафик этого конкретного TCP-соединения идёт зашифрованным. Если вам интересны детали самого рукопожатия — это разобрано отдельно в статье про TLS-рукопожатие и что происходит до первого байта.

Что это реально даёт: сетевой перехват на этом конкретном участке (провайдер, узел Wi-Fi, транзитный роутер, кто-то с доступом к каналу связи между А и Б) видит только зашифрованный трафик. Прочитать содержимое письма, просто снифферя сеть между этими двумя серверами, нельзя.

Проверить, что STARTTLS вообще предлагается сервером, можно вручную:

openssl s_client -starttls smtp -connect mail.example.com:25 -crlf

В ответе ищите строку 250-STARTTLS в списке возможностей сервера (EHLO-ответ) и убедитесь, что после STARTTLS соединение действительно переходит в TLS (появляется информация о сертификате, а не обрыв). Для порта 587 (submission, обычно между вашим почтовым клиентом и вашим сервером) команда аналогичная, только -connect mail.example.com:587.

Важный нюанс: STARTTLS в классической реализации — это oportunistic TLS. Если по какой-то причине рукопожатие не удалось (несовместимые версии протокола, проблема с сертификатом, активный MITM, который просто вырезает команду STARTTLS из ответа — атака известна как STARTTLS stripping), многие сервера по умолчанию откатятся на обычную незашифрованную передачу, просто чтобы письмо всё-таки дошло. Современные защиты вроде MTA-STS и DANE как раз призваны закрыть эту дыру, заставляя сервер требовать TLS и падать, а не откатываться, — но они настроены далеко не везде, и надеяться, что оба сервера в цепочке их поддерживают, не стоит.

Что происходит с письмом внутри сервера — открытым текстом

Вот здесь начинается главное расхождение с бытовым представлением о «зашифрованной почте».

Путь письма от вас до получателя — это обычно не одно соединение, а цепочка: ваш почтовый клиент → ваш исходящий сервер (submission) → возможно, релей или спам-фильтр → сервер получателя (может быть несколько MX с балансировкой) → почтовый ящик получателя. TLS, если настроен, шифрует каждый отдельный отрезок этой цепочки. Но на каждом узле письмо в какой-то момент оказывается расшифрованным — потому что серверу физически необходимо прочитать заголовки (From, To, Subject, маршрутизацию), применить спам-фильтры, антивирусные проверки, правила пересылки, записать письмо в очередь или в файл на диске (mbox, Maildir) — а всё это невозможно сделать, не имея доступа к открытому содержимому.

Отсюда прямое следствие: администратор любого промежуточного сервера — вашего собственного почтового сервера, релея вашего провайдера, сервера получателя, любого MX по пути — технически может прочитать содержимое письма. Не потому что TLS плохо настроен, а потому что TLS вообще не про это. TLS защищает от постороннего в сети между двумя серверами, а не от того, кто управляет одним из этих серверов.

Это ровно та же логика, что и с шифрованием диска на сервере: технология защищает от одной конкретной угрозы (кражи физического носителя), но не от всех остальных — подробнее разобрано в статье про то, что реально защищает шифрование дисков. С почтовым TLS то же самое: он закрывает конкретную дыру (перехват в сети), а не превращает письмо в неприкосновенное содержимое на всём пути.

Если вы держите собственный почтовый сервер (например, через iRedMail или Mailcow — этому посвящены отдельные статьи по установке), это стоит держать в голове буквально: письма ваших пользователей физически лежат на диске вашего VPS в читаемом виде, пока получатель их не заберёт. TLS между вашим сервером и сервером получателя защищает канал, но не файл на диске.

Сквозное шифрование: PGP/GPG и S/MIME — вот что реально скрыто от посредников

Сквозное (end-to-end) шифрование содержимого решает именно ту проблему, которую TLS не решает: оно шифрует тело письма до того, как оно уходит с устройства отправителя, ключом, который есть только у получателя. Промежуточные серверы видят только зашифрованный блок данных — прочитать его не может ни ваш почтовый сервер, ни релей провайдера, ни сервер получателя, ни кто-либо ещё, кроме владельца приватного ключа.

Два основных подхода:

• PGP/GPG — асимметричное шифрование, где отправитель шифрует письмо публичным ключом получателя, а расшифровать может только приватный ключ получателя. Не завязан на конкретного провайдера почты, ключи можно хранить где угодно, публиковать через keyserver или обмениваться вручную.
• S/MIME — похожая идея, но ключи выдаются через сертификаты X.509, обычно через корпоративный или коммерческий удостоверяющий центр. Чаще встречается в корпоративной среде, где уже есть инфраструктура сертификатов.

Принципиальное отличие от TLS — это не автоматическая, прозрачная технология. TLS между серверами обычно включается один раз в конфигурации и дальше работает без участия пользователей на каждый конкретный разговор. PGP и S/MIME требуют, чтобы:

1. У отправителя был настроен собственный ключ (сгенерирован, при желании подписан).
2. У получателя тоже был ключ, а отправитель имел его публичную часть заранее.
3. Оба пользователя реально включили шифрование в почтовом клиенте для конкретного письма (плагин, встроенная поддержка, ручная команда gpg --encrypt).

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

Пример шифрования файла публичным ключом получателя из командной строки:

gpg --encrypt --recipient ivan@example.com --armor message.txt

Результат — файл в текстовом ASCII-armor формате, который можно вставить в тело письма или приложить; расшифровать его сможет только владелец приватного ключа ivan@example.com.

Метаданные не прячутся даже при сквозном шифровании

Вот нюанс, который обычно упускают даже те, кто в целом понимает разницу между TLS и PGP: сквозное шифрование защищает содержимое, но не факт и контекст переписки.

Заголовки конверта письма — кто отправитель, кто получатель, через какие сервера письмо прошло (цепочка Received:), когда оно было отправлено, размер письма, а в классической реализации PGP/MIME зачастую и тема письма (Subject) — остаются видны на каждом промежуточном сервере в открытом виде. Это неизбежное следствие того, как устроена маршрутизация почты: серверу нужно прочитать «кому доставить», иначе он просто не сможет доставить письмо.

Это значит, что даже при идеально настроенном PGP администратор почтового сервера (ваш собственный или сервера получателя) не может прочитать, что написано в письме, но прекрасно видит: кто кому писал, как часто, в какое время суток, какого объёма были письма и какая у них была тема (если она не защищена отдельно). Для многих реальных угроз — юридического давления, корпоративного надзора, анализа связей — этого метаданного зачастую достаточно, даже без единого прочитанного слова из тела письма.

Отдельные схемы (некоторые реализации PGP/MIME, протокол шифрования темы в отдельных клиентах) пытаются скрыть и тему письма, но это не универсальная гарантия — зависит от конкретного клиента и договорённости с получателем, и рассчитывать на это по умолчанию не стоит.

Что с этим делать на практике: два разных уровня ожиданий

Полезно развести два сценария и не пытаться решить их одним и тем же инструментом.

Обычная повседневная деловая переписка. Здесь реалистичная и достаточная цель — убедиться, что TLS транспортного уровня работает корректно на вашем домене: STARTTLS отвечает, сертификат валиден и не просрочен, в идеале настроены MTA-STS и/или DANE, чтобы TLS не откатывался на обычную передачу при сбое рукопожатия. Это закрывает самую массовую и дешёвую для атакующего угрозу — пассивный перехват трафика в сети. Не нужно требовать от каждого сотрудника генерировать PGP-ключи ради письма про перенос созвона.

Действительно чувствительное содержимое — юридические документы, финансовые детали, персональные данные, которые не должны быть доступны даже вашему собственному почтовому администратору или администратору сервера получателя. Здесь TLS в принципе не решает задачу, сколько бы вы его ни настраивали: нужно сквозное шифрование содержимого, договорённость с конкретным получателем об обмене ключами и настроенный на обеих сторонах клиент. Это дополнительная работа и обычно разовая настройка на каждого нового собеседника — но только она даёт гарантию, о которой люди на самом деле думают, когда говорят «зашифрованная почта».

Сравнение по фактам:

Если вы переносите почту на собственный сервер (например, при переходе с Gmail на свой почтовый сервер), первый практический шаг — проверить именно TLS-конфигурацию нового сервера тем же openssl s_client, а не полагаться на то, что «раз это HTTPS-панель управления, значит и почта защищена» — это тот же порядок ошибки, что разобран в статье про миф «HTTPS значит сайт безопасный»: один защищённый канал не означает защищённость всего остального.

Частые вопросы