S/MIME и PGP: два подхода к шифрованию email

SPF, DKIM и DMARC подтверждают, что письмо отправил тот, кто указан в поле From. Но они не скрывают содержимое. Любой сервер на маршруте может прочитать тело письма, если захочет. Шифрование решает другую задачу: сделать текст нечитаемым для всех, кроме отправителя и получателя. Для этого существуют два стандарта - S/MIME и PGP. Оба живут с 90-х, оба работают, но устроены по-разному.

От чего на самом деле защищает шифрование почты

SMTP придумали в 1982 году, и протокол передаёт письма открытым текстом. TLS между почтовыми серверами (оппортунистический STARTTLS или MTA-STS) шифрует соединение, но не само письмо. Как только оно легло на принимающий сервер, оно лежит там незашифрованным. Администратор сервера, судебное решение или утечка откроют каждое слово.

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

С девяностых дожили два стандарта: S/MIME (Secure / Multipurpose Internet Mail Extensions) и PGP (Pretty Good Privacy), который сегодня чаще используют через открытую спецификацию OpenPGP. Задачу они решают одну, шифруют и подписывают письма, но по-разному устроены в части доверия и раздачи ключей.

S/MIME: сертификаты от центра сертификации

S/MIME стоит на сертификатах X.509, на той же инфраструктуре PKI, что и HTTPS. Центр сертификации проверяет вашу личность и выдаёт сертификат, который связывает ваш адрес почты с открытым ключом. Закрытый ключ остаётся на вашем устройстве.

The flow for sending an encrypted message:

1. Вы получаете сертификат S/MIME получателя, обычно он приходит сам, когда тот присылает вам подписанное письмо.
2. Ваш почтовый клиент шифрует тело и вложения открытым ключом получателя.
3. Расшифровать письмо может только закрытый ключ получателя.

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

Где взять сертификат S/MIME

К 2026 году бесплатные сертификаты S/MIME почти исчезли. Actalis ещё выдаёт бесплатные для личного использования (проверяется только почта, срок год). Организациям DigiCert, Sectigo и GlobalSign продают сертификаты примерно от 20-40 долларов в год за адрес. Корпоративные планы с централизованным управлением дороже, зато упрощают развёртывание на сотни ящиков.

Поддержка в клиентах

Вот в этом главная сила S/MIME. Outlook (настольный и веб), Apple Mail, iOS Mail и Thunderbird поддерживают его из коробки, плагины не нужны. Gmail тоже поддерживает, но только для аккаунтов Google Workspace на планах Business Plus, Enterprise и Education, с бесплатным Gmail это не работает. Когда сертификат установлен, подпись и шифрование включаются прямо в окне написания письма, обычно значком замка.

Ограничения

• Стоимость сертификата. На команду в 50 человек по 30 долларов в год выходит заметная сумма. Бюджет не огромный, но и не нулевой.
• Риск депонирования ключей. Некоторые центры сертификации и корпоративные развёртывания хранят копии закрытых ключей. Если такой архив утечёт, старую переписку можно расшифровать. Прямой секретности в стандарте S/MIME нет.
• Срок действия сертификата. Сертификаты истекают, обычно через 1-3 года. После этого старые подписанные письма могут показывать предупреждения, а зашифровать на истёкший сертификат не выйдет. Продление делается руками, если у вас нет MDM или инструмента управления жизненным циклом сертификатов.
• Централизованное доверие. Если центр сертификации взломан или выдал поддельный сертификат, ломается вся цепочка. С центрами для HTTPS такое уже случалось, а экосистема S/MIME меньше и проверяется хуже.

PGP и OpenPGP: децентрализованное доверие

Фил Циммерман выпустил PGP в 1991 году. Основная мысль: никакого центрального органа. Пару ключей вы создаёте сами. Открытый ключ публикуете на сервере ключей, на своём сайте или отдаёте контактам напрямую. Доверие строится через «сеть доверия», когда другие люди подписывают ваш ключ, ручаясь за его подлинность, либо через прямую проверку, например сверку отпечатков по телефону.

Современная открытая спецификация называется OpenPGP (RFC 9580, обновлён в 2024-м). Самая распространённая бесплатная реализация это GnuPG (GPG). Есть и другие: Sequoia PGP и библиотека OpenPGP.js, которую использует Proton Mail.

Как устроено шифрование

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

Раздача ключей: самое сложное

S/MIME едет на инфраструктуре центров сертификации, которая и так существует для веба. У PGP такой роскоши нет. Надёжно получить чужой открытый ключ и есть главная задача. У классической сети серверов ключей SKS были проблемы: никакой проверки личности, атаки переполнением сертификатов и конфликт с GDPR. Современные варианты лучше: keys.openpgp.org требует подтверждения почты перед публикацией, а WKD (Web Key Directory) позволяет выкладывать ключи на собственном домене.

WKD lookup example for alice@example.com:

GET https://openpgpkey.example.com/.well-known/openpgpkey/example.com/hu/<hash>
# or direct method:
GET https://example.com/.well-known/openpgpkey/hu/<hash>

Если ваша организация управляет своим DNS и веб-сервером, настройка WKD занимает около часа. После этого любой клиент с поддержкой OpenPGP забирает ключи вашей команды автоматически, без ручного обмена. import.

Поддержка в клиентах

Вот тут у PGP слабое место. Outlook OpenPGP не поддерживает. Apple Mail тоже. Из настольных клиентов встроенная поддержка есть у Thunderbird (с 78-й версии). Остальным нужны плагины: Gpg4win с GpgOL для Outlook под Windows, GPGMail для Apple Mail (платный, от GPGTools). На мобильных выбор скудный: OpenKeychain под Android работает с K-9 Mail и Thunderbird для Android, на iOS вариантов почти нет.

Веб-решения вроде Proton Mail и Mailvelope (расширение браузера для Gmail и не только) прячут сложность за простым интерфейсом. Proton Mail особенно: там PGP прозрачен, человек шифрует и расшифровывает, ни разу не открыв диалог управления ключами. Но работает это только между пользователями Proton или когда внешний получатель опубликовал свой ключ OpenPGP.

S/MIME против PGP: прямое сравнение

Однозначно лучшего протокола тут нет. S/MIME выигрывает в простоте развёртывания там, где стандартом стоит Outlook или Apple Mail. PGP выигрывает в цене, децентрализации и гибкости для технических пользователей, которые не доверяют централизованным центрам сертификации.

Когда шифрование действительно нужно

Большинству маркетинговых рассылок шифрование не нужно. Вы не отправляете секретные данные в промо-письме о скидке 15%. Шифрование необходимо, когда содержимое письма имеет ценность для третьих лиц или когда утечка может нанести ущерб.

Конкретные сценарии, где шифрование оправдано:

• Персональные данные по ФЗ-152 / GDPR. Если вы передаёте сотруднику или партнёру файл с паспортными данными, медицинской информацией или финансовыми записями, закон требует принять меры защиты. Шифрование email - одна из них.
• Юридическая переписка. Адвокатская тайна не защищена, если письмо может прочитать администратор почтового сервера. Многие юридические фирмы в США и Европе перешли на S/MIME для корпоративной почты.
• Финансовые отчёты. Квартальные результаты до публичного объявления, M&A-документы, внутренние прогнозы - всё, что влияет на биржевую стоимость.
• Журналистика и активизм. Защита источников. Whistleblower-каналы многих СМИ используют PGP: The Guardian, The New York Times, ProPublica публикуют свои PGP-ключи для защищённой связи.
• Внутренние коммуникации в оборонке и госсекторе. Здесь шифрование часто регулируется отраслевыми стандартами, а не выбором конкретного сотрудника.

Когда шифрование избыточно

Маркетинговая рассылка - открытое сообщение. Вы хотите, чтобы его прочитали. Шифрование только мешает: получатель без соответствующего ключа увидит нечитаемый blob вместо письма. Массовая отправка зашифрованных email технически возможна (шифровать каждое письмо отдельным ключом каждого получателя), но ни один ESP этого не поддерживает, и смысла в этом нет.

Транзакционные письма - чеки, подтверждения регистрации, сброс пароля - тоже обычно не шифруют. TLS между серверами обеспечивает защиту в транзите. MTA-STS делает TLS принудительным, а не опциональным. Для большинства транзакционных сценариев этого достаточно. Если вы хотите убедиться, что TLS используется, настройте MTA-STS для своего домена и мониторьте отчёты TLS-RPT.

Практическая настройка: S/MIME в Outlook

Для организации, где основной клиент - Outlook, S/MIME - наименее болезненный путь. Вот что нужно сделать:

1. Купить S/MIME сертификаты у CA (Sectigo, DigiCert). Для организации - Organization Validated (OV) сертификат. Он показывает имя компании в подписи.
2. Экспортировать сертификат в формате .pfx (PKCS#12). Файл содержит и публичный сертификат, и приватный ключ, защищённый паролем.
3. Импортировать .pfx в Windows Certificate Store или развернуть через Active Directory / Intune для централизованного управления.
4. В Outlook: File → Options → Trust Center → Email Security → выбрать сертификат для подписи и шифрования.
5. Отправить подписанное письмо коллеге. Коллега автоматически получит ваш публичный сертификат. Теперь он может шифровать письма вам.

В Microsoft 365 Admin Center можно включить S/MIME для всей организации, загрузить корневые и промежуточные сертификаты CA, и задать политику: подписывать все исходящие по умолчанию, шифровать при наличии сертификата получателя.

Практическая настройка: PGP в Thunderbird

Thunderbird - единственный крупный клиент с встроенной поддержкой OpenPGP без плагинов. Настройка:

1. Account Settings → End-To-End Encryption → Add Key. Можно сгенерировать новый или импортировать существующий.
2. Рекомендуемые параметры: Ed25519 для подписи, Curve25519 для шифрования. Если нужна совместимость со старыми системами - RSA 4096.
3. Опубликовать публичный ключ: экспортировать как .asc файл и загрузить на keys.openpgp.org. Или настроить WKD на своём домене.
4. Для отправки зашифрованного письма: импортировать публичный ключ получателя. Thunderbird умеет автоматически искать ключи через WKD и keys.openpgp.org.

# Генерация ключа через GPG CLI (альтернатива)
gpg --quick-gen-key "Ivan Petrov <ivan@example.com>" ed25519 sign 2y
gpg --quick-add-key <fingerprint> cv25519 encrypt 2y

# Экспорт публичного ключа
gpg --armor --export ivan@example.com > ivan-public.asc

# Настройка WKD (прямой метод)
# Положить файл в:
# https://example.com/.well-known/openpgpkey/hu/<sha1-hash-of-localpart>

Типичные ошибки при внедрении

• Нет бэкапа приватного ключа. Сотрудник переустановил ОС - ключ потерян. Все зашифрованные письма, которые он получил, больше не читаются. Никогда. Для S/MIME: экспортируйте .pfx и храните в защищённом месте. Для PGP: экспортируйте приватный ключ (gpg --export-secret-keys) и положите на зашифрованный носитель.
• Шифрование без подписи. Шифрование скрывает содержимое, но не подтверждает отправителя. Без подписи получатель не может быть уверен, что зашифрованное письмо пришло именно от вас. Включайте подпись всегда.
• Хранение ключей на почтовом сервере. Некоторые решения предлагают серверное шифрование: ключ хранится на сервере, а шифрование/дешифрование происходит там же. Это не end-to-end. Компрометация сервера раскрывает всё. Ключи должны быть на устройстве пользователя.
• Забыли про тему письма. Ни S/MIME, ни PGP не шифруют Subject. Тема письма передаётся открытым текстом. Если в теме написано «Конфиденциально: сделка по поглощению X», шифрование тела не поможет. Держите тему нейтральной.
• Не проверили, что получатель может расшифровать. Отправили зашифрованное письмо человеку, у которого нет настроенного ключа. Он видит вложение smime.p7m и не понимает, что с ним делать. Перед внедрением убедитесь, что обе стороны готовы.

Шифрование и аутентификация - разные задачи

Путаница между ними - частое явление. SPF, DKIM и DMARC - это аутентификация: они подтверждают, что письмо пришло от легитимного отправителя, и что оно не было подменено на маршруте. Но они не скрывают содержимое. S/MIME и PGP - это шифрование и подпись на уровне сообщения: содержимое закрыто от посторонних, а подпись подтверждает авторство конкретного человека (не домена, а именно владельца ключа).

Для массовых рассылок вам нужна аутентификация: SPF, DKIM, DMARC, возможно BIMI. Для конфиденциальной переписки один на один - шифрование. Это не взаимоисключающие вещи: зашифрованное PGP-письмо тоже проходит SPF/DKIM-проверки (они работают на уровне заголовков и конверта, а не тела).

Альтернативы: когда email - не лучший канал

Если настройка S/MIME или PGP кажется слишком тяжёлой для вашей задачи, есть более простые варианты. Защищённый портал (отправляете ссылку на документ за авторизацией), мессенджеры с E2EE (Signal), защищённые файлообменники. Для разовой передачи конфиденциального документа портальный подход проще, чем развёртывание PKI.

Но если конфиденциальная переписка - регулярная часть вашей работы (юриспруденция, медицина, финансы), вложение в S/MIME или PGP окупается. Один раз настроить - и каждое письмо защищено автоматически. Никаких ссылок, никаких порталов, никаких дополнительных действий при каждой отправке.

Итог

S/MIME - для организаций, где Outlook или Apple Mail являются стандартом, есть бюджет на сертификаты и централизованное управление через AD/MDM. PGP - для технически грамотных пользователей, журналистов, разработчиков, и организаций, которые принципиально не хотят зависеть от центрального удостоверяющего центра. Оба стандарта решают задачу шифрования. Ни один не решает задачу доставляемости.

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