Коротко. Сквозное шифрование (по-английски end-to-end encryption, E2EE) шифрует сообщение на устройстве отправителя, а расшифровывает только на устройстве получателя. Все, кто передаёт и хранит сообщение по дороге, включая почтовые серверы, видят вместо содержимого только набор бессмысленных символов. Ключи для расшифровки есть только у участников переписки.
Представьте запертую шкатулку
Вы кладёте письмо в шкатулку и запираете её. Ключ от замка есть только у получателя. Курьер везёт шкатулку через весь город, заходит на склады, передаёт коллегам. Открыть её не может никто из них.
Но адрес написан на шкатулке снаружи. Иначе курьер не знал бы, куда её везти. С электронной почтой так же: содержимое можно спрятать, а адрес доставки нельзя. К этому мы ещё вернёмся.
Как это устроено
Сквозное шифрование почти всегда опирается на пару ключей.
- Открытый ключ можно раздавать всем. Им шифруют сообщения для владельца ключа.
- Закрытый ключ хранится только на устройстве владельца. Только им можно расшифровать то, что зашифровали открытым [10].
Когда вы отправляете зашифрованное письмо, программа делает три шага:
- создаёт случайный одноразовый ключ и шифрует им текст и вложения;
- шифрует этот одноразовый ключ открытым ключом получателя;
- отправляет оба результата вместе.
Получатель своим закрытым ключом расшифровывает одноразовый ключ, а им уже само письмо. Так устроены, например, стандарты OpenPGP и S/MIME [1, 2].
Часто к письму добавляют ещё и цифровую подпись. Её ставят закрытым ключом отправителя, а проверяют открытым. Подпись показывает, что письмо написал владелец ключа и что по дороге его не изменили.
«Зашифровано» ещё не значит «сквозное шифрование»
Слово «шифрование» в описании почтового сервиса может означать три разные вещи. Главный вопрос в каждом случае один: у кого ключи.
| Вид шифрования | Что защищает | У кого ключи | Кто может прочитать письмо |
|---|---|---|---|
| При передаче (TLS) | путь письма от устройства до сервера и между серверами | у серверов на каждом участке | каждый сервер по дороге |
| При хранении | диски сервиса от кражи и посторонних | у сервиса | сервис |
| Сквозное | содержимое: текст и вложения, от устройства до устройства | только у отправителя и получателей | только отправитель и получатели |
Бывает и четвёртый вариант: хранение с нулевым доступом. Письма лежат зашифрованными ключами пользователя, и сервис не может прочитать хранимое. Письмо с другого сервиса он при этом всё равно видит в момент приёма.
Первые два вида из таблицы полезны и нужны. Но при них сервис, который хранит почту, технически может её прочитать. Сквозное шифрование закрывает именно эту возможность.
Почему обычная почта не шифруется сквозным образом
Электронная почта старше массового шифрования, и её устройство это отражает.
- Серверы передают письма друг другу по протоколу SMTP [3]. Шифрование между серверами (STARTTLS) добавили позже, как расширение [4]. Оно «оппортунистическое»: если сервер на другой стороне шифрование не поддерживает или его по дороге отключил атакующий в сети, письмо может уйти открытым [5]. Стандарт MTA-STS позволяет домену потребовать шифрование при доставке, но работает, только если домен получателя его настроил, а сервер отправителя его поддерживает [6].
- Письма хранятся на сервере. Поиск, фильтр спама и веб-версия обычных сервисов работают с письмами на сервере, и для этого серверу нужно их содержимое.
- Ключей нет у большинства адресатов. Сквозное шифрование работает, только если у получателя тоже есть ключ и программа, которая понимает тот же стандарт.
Поэтому крупные сервисы обычно шифруют письма при передаче и при хранении, но не сквозным образом. Apple, например, прямо пишет, что Почта iCloud не использует сквозное шифрование из-за необходимости работать с глобальной почтовой системой (по данным Apple на сентябрь 2026 года) [7].
Как шифруют почту сквозным образом
Есть два открытых стандарта.
- OpenPGP [1]. Ключи создаёт и хранит сам пользователь. Открытый ключ можно опубликовать или отправить собеседнику. Последняя версия стандарта вышла в 2024 году.
- S/MIME [2]. Ключи привязаны к сертификатам, которые обычно выдаёт удостоверяющий центр. Чаще встречается в компаниях.
Письмо, зашифрованное по OpenPGP или S/MIME, можно отправить с любого почтового сервиса. Но прочитать его сможет только адресат, у которого есть подходящий ключ и программа.
Некоторые почтовые сервисы встраивают сквозное шифрование прямо в свои приложения: письма между их пользователями шифруются автоматически. Для адресатов на других сервисах у них обычно есть отдельные способы. Как проверить, что сервис действительно так делает, описано в конце статьи.
Что остаётся видно даже в зашифрованном письме
Сквозное шифрование прячет содержимое. Но почта не может доставить письмо, не зная, откуда и куда оно идёт. Даже определение из глоссария NIST оговаривает: при сквозном шифровании данные защищены, а сведения о маршруте остаются видны [8].
Обычно видно:
- адреса отправителя и получателей: без них письмо не доставить;
- время отправки и размер письма;
- серверы, через которые прошло письмо: они записаны в служебных заголовках;
- тема письма. В классических OpenPGP и S/MIME тема не шифруется. Стандарт защиты заголовков вышел в 2025 году [9], но поддерживают его пока не все программы.
Такие сведения называют метаданными: кто, кому, когда. Иногда они говорят о человеке не меньше, чем сам текст.
От чего сквозное шифрование не защищает
Сквозное шифрование решает одну задачу: чтобы письмо не прочитали по дороге и на серверах. Остальное оно не закрывает.
- Вредоносная программа на устройстве. Если устройство взломано, программа увидит письмо уже расшифрованным.
- Получатель. Письмо можно переслать, распечатать или сфотографировать экран.
- Потеря ключа. Если закрытый ключ потерян, а резервной копии нет, старые письма не расшифровать. Никому.
- Веб-версия. Почта в браузере загружает свой код с сервера при каждом входе. Если у сервиса нет механизма проверки этого кода, остаётся доверять, что его не подменили.
- Метаданные. Они остаются видны, об этом раздел выше.
Как проверить, что сервис шифрует сквозным образом
Если сервис пишет о шифровании, задайте ему пять вопросов.
- Где создаются и хранятся ключи? Если закрытый ключ лежит у сервиса в открытом виде или зашифрован ключом, который тоже есть у сервиса, шифрование не сквозное.
- Что именно шифруется? Только текст и вложения или ещё тема, контакты, черновики?
- Открыт ли код приложений, опубликован ли независимый аудит? Без этого остаётся верить на слово.
- Можно ли сверить ключ собеседника? Например, сравнить отпечаток ключа при встрече или по другому каналу связи. Или сервис публикует ключи в проверяемом журнале: это называют прозрачностью ключей.
- Что происходит с письмами с других сервисов? Они приходят обычной почтой, и сервис видит их в момент приёма.
Словарик
- Сквозное шифрование (E2EE): шифрование от устройства отправителя до устройства получателя; ключи есть только у участников переписки.
- TLS: шифрование канала связи между двумя точками, например между вашим устройством и сервером.
- Открытый и закрытый ключ: пара ключей; открытым шифруют, закрытым расшифровывают.
- OpenPGP и S/MIME: открытые стандарты сквозного шифрования почты.
- Метаданные: сведения о письме, а не его содержание: кто, кому, когда, какого размера.
Источники
- RFC 9580: OpenPGP. IETF, июль 2024. https://www.rfc-editor.org/rfc/rfc9580
- RFC 8551: S/MIME Version 4.0 Message Specification. IETF, апрель 2019. https://www.rfc-editor.org/rfc/rfc8551
- RFC 5321: Simple Mail Transfer Protocol. IETF, октябрь 2008. https://www.rfc-editor.org/rfc/rfc5321
- RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security. IETF, февраль 2002. https://www.rfc-editor.org/rfc/rfc3207
- RFC 7435: Opportunistic Security: Some Protection Most of the Time. IETF, декабрь 2014. https://www.rfc-editor.org/rfc/rfc7435
- RFC 8461: SMTP MTA Strict Transport Security (MTA-STS). IETF, сентябрь 2018. https://www.rfc-editor.org/rfc/rfc8461
- Apple: обзор безопасности данных iCloud. https://support.apple.com/ru-ru/102651
- NIST SP 800-12 Rev. 1, глоссарий CSRC: end-to-end encryption. https://csrc.nist.gov/glossary/term/end_to_end_encryption
- RFC 9788: Header Protection for Cryptographically Protected Email. IETF, август 2025. https://www.rfc-editor.org/rfc/rfc9788
- EFF, Surveillance Self-Defense: A Deep Dive on End-to-End Encryption. https://ssd.eff.org/module/deep-dive-end-end-encryption-how-do-public-key-encryption-systems-work