Веб

Сквозное шифрование в Gmail и Yandex.Почте: поддержка?

Поддерживают ли Gmail и Yandex.Почта сквозное (end-to-end) шифрование писем? Узнайте о TLS для передачи, серверном хранении и способах настройки PGP/S/MIME для настоящего E2E. Шифрование почты в этих сервисах не по умолчанию.

Поддерживают ли Gmail и Yandex.Почта сквозное (end-to-end) шифрование писем? Шифруются ли сообщения при передаче и хранятся ли они в зашифрованном виде на серверах этих сервисов?

Gmail и Yandex.Почта по умолчанию не предоставляют полноценного сквозного (end-to-end) шифрования писем: шифрование почты реализовано главным образом как защищённая передача (TLS) и серверное шифрование при хранении, но провайдеры обычно имеют доступ к содержимому. Электронная почта шифрование в этих сервисах есть — TLS защищает сообщения в пути, а данные на серверах зашифрованы на уровне инфраструктуры — но это не равно E2E. Настоящее сквозное шифрование можно получить только при использовании S/MIME или PGP (или специальных клиентских/корпоративных решений), и тогда обе стороны должны корректно настроить ключи.


Содержание


Как Gmail шифрует письма — транспорт и хранение (шифрование gmail)

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

  • Передача: Gmail автоматически использует TLS для защиты почты при передаче между клиентом и серверами Google и между почтовыми серверами. Если соединение с почтовым сервером получателя поддерживает TLS, обмен шифруется по сети; если нет — письмо может уйти в открытом виде (оппортунистическое шифрование). Подробнее — в справке Gmail по шифрованию передач: https://support.google.com/mail/answer/6330403?hl=ru.
  • Хранение: внутри инфраструктуры Google данные шифруются на уровне хранения (encryption at rest), но это серверное шифрование: ключи обычно контролируются сервисом (или — в корпоративных настройках — клиентом/администратором), и сообщения могут быть доступны сервису для функций (поиск, фильтрация и т.д.). См. описание клиентского и серверного шифрования в Google Workspace: https://support.google.com/mail/answer/13317990?hl=ru.
  • Корпоративные опции: для организаций в Google Workspace доступны S/MIME и (в некоторых релизах/бета‑функциях) клиентское шифрование, при котором шифрование выполняется в браузере/клиенте до отправки. Даже в этих режимах заголовки (тема, список получателей, дата) обычно остаются незашифрованными, а доступность функции зависит от настроек администратора и конфигурации получателя — подробнее про клиентское шифрование: https://support.google.com/mail/answer/13317990?hl=ru.

Что это значит простыми словами? Если вы отправляете письмо с обычного Gmail на другой современный почтовый сервис — пересылка по сети будет защищена TLS. Но Google как провайдер хранит и обрабатывает сообщения; полноценное E2E‑невмешательство достигается только при использовании независимого клиентского шифрования (S/MIME/PGP) либо специальных режимов Workspace.


Как Яндекс.Почта шифрует письма — транспорт и хранение (шифрование почты яндекс)

Yandex.Почта тоже делает упор на защищённую передачу и защищённые соединения клиента с сервером, но не на встроенное E2E:

  • Передача и протоколы: для обмена Яндекс использует SSL/TLS (включая STARTTLS для межсерверных SMTP-соединений). В web‑интерфейсе и при работе с почтовыми клиентами рекомендуется включать SSL/TLS (IMAP 993, POP3 995, SMTP 465 и т.п.) — официальные инструкции: https://yandex.ru/support/mail/mail-clients/ssl.html. Блог почты Яндекса подробно рассказывал про внедрение TLS и поведение при отсутствии шифрованного соединения: https://yandex.ru/blog/mail/17481.
  • Хранение: внутри инфраструктуры Яндекса сообщения не шифруются «сквозным» образом для провайдера: сервисы и администраторы имеют возможность доступа к содержимому (сообщения хранятся в виде, доступном для внутренних сервисов), то есть серверное шифрование, если применяется на уровне дисков, не равнозначно E2E‑шифрованию. Подробно — в поддержке и разборе на Habr: https://habr.com/ru/companies/yandex/articles/203882/.
  • Межсерверные нюансы: если сервер получателя не поддерживает TLS, Яндекс может отправить письмо без шифрования (оппортунистическое поведение). STARTTLS тоже может быть уязвим к понижению протокола, если не приняты дополнительные меры (MTA‑STS/DANE).

Практический вывод: для защиты в пути и между клиентом и сервером Яндекс обеспечивает TLS/SSL, но чтобы получить настоящее E2E, придётся настроить PGP/S/MIME в почтовом клиенте — веб‑интерфейс Яндекса не даёт встроенного управления PGP‑ключами.


Поддерживают ли Gmail и Yandex сквозное (end-to-end) шифрование?

Коротко: нет, не для всех пользователей и не по умолчанию.

Подробнее по сервисам:

  • Gmail: по умолчанию — нет полного E2E для всех писем; стандартная защита — TLS и серверное шифрование. Для корпоративных клиентов Google Workspace доступны S/MIME и опции клиентского шифрования (CSE), которые приближают поведение к E2E: в режиме клиентского шифрования тело письма и вложения шифруются на стороне клиента, но заголовки остаются незашифрованными, а функция требует настройки администратора и совместимости получателя — https://support.google.com/mail/answer/13317990?hl=ru и https://support.google.com/mail/answer/6330403?hl=ru.
  • Yandex.Почта: по умолчанию E2E не реализовано; используется TLS/SSL для передачи, а хранение делается в инфраструктуре провайдера без клиентского шифрования. Чтобы добиться E2E, нужно применять PGP/GPG или S/MIME вне веб‑интерфейса (через настольный/мобильный клиент) — см. инструкции по SSL/TLS и заметки в блоге Яндекса: https://yandex.ru/support/mail/mail-clients/ssl.html и https://yandex.ru/blog/mail/17481.

Условие «получатель тоже должен поддерживать» — критично. Сотрудничать с защищённым обменом можно только если обе стороны обменялись ключами или используют совместимые E2E‑решения. И ещё: даже при E2E многие реализации не скрывают метаданные (кому, когда и тему почты), так что «полная анонимность» не достигается только шифрованием тела.


Как получить настоящее сквозное шифрование (S/MIME, PGP, клиентское шифрование)

Если цель — чтобы провайдер не мог прочитать тело письма, варианты такие:

  1. PGP/OpenPGP (подходит для частных и корпоративных пользователей)
  • Суть: генерируете пару ключей (публичный + приватный). Отправитель шифрует письма публичным ключом получателя; расшифровать может только владелец приватного ключа.
  • Как начать (упрощённо):
  • Сгенерировать ключ: gpg --full-generate-key (или через GUI клиента).
  • Передать публичный ключ получателям (или опубликовать на доверенном месте).
  • Настроить почтовый клиент: Thunderbird (OpenPGP встроен), Mailvelope (расширение для браузера), K‑9 + OpenKeychain на Android.
  • Проверить отпечатки ключей по защищённому каналу.
  • Минусы: настройка и управление ключами — ручные, потеря приватного ключа — потеря писем, не все получатели готовы.
  1. S/MIME (часто в компаниях)
  • Требует сертификатов от центров сертификации и поддержки в почтовом клиенте. Обычно применяется в корпоративной почте (Google Workspace поддерживает S/MIME при соответствующей конфигурации).
  • Плюс: централизованная система и корпоративная поддержка. Минус: требуется инфраструктура сертификатов, сложнее в частной переписке.
  1. Клиентское шифрование в Google Workspace (CSE)
  • Для организаций: администратор включает режимы клиентского шифрования; тело и вложения шифруются до отправки в браузере/клиенте. Но опция доступна не всем пользователям и имеет ограничения (например, незашифрованные заголовки) — https://support.google.com/mail/answer/13317990?hl=ru.
  1. Специальные «безопасные» почтовые сервисы
  • Сервисы, которые по дизайну обеспечивают E2E между пользователями одного сервиса (например, ProtonMail, Tutanota и т.п.). Они также предлагают способы отправлять зашифрованные сообщения внешним адресатам. (Эти сервисы не разграничены в источниках выше, но это общепринятое решение.)

Короткие рекомендации:

  • Если нужно, чтоб провайдер не читал ваши письма — используйте PGP/S/MIME и храните приватный ключ только у себя.
  • Если нужна удобная корпоративная защита — рассмотрите Google Workspace с S/MIME или CSE.
  • Для разовых защищённых сообщений — парольная защита вложений или зашифрованные архивы могут быть практичным компромиссом.

Ограничения и риски

Несколько важных ограничений, о которых стоит помнить:

  • Метаданные остаются видимыми. Даже при E2E большинство схем не скрывают заголовки (кому/от кого/тема/дата) — это видно провайдеру и почтовым серверам.
  • Совместимость. Для полноценного E2E обе стороны должны настроить и доверять ключам; массовое использование встраиваемых клиентских функций ограничено.
  • Удобство против безопасности. E2E ломает или ограничивает серверные функции: полнотекстовый поиск, антиспам/антивирусную проверку, бэкапы.
  • Управление ключами — боль. Потеря приватного ключа — потеря доступа к письмам; компрометация ключа — утечка.
  • Правовые и операционные риски. Если ключи хранятся у провайдера (серверное шифрование с управлением ключами провайдера), провайдер может расшифровать по требованию (например, правоохранительных органов).
  • TLS не равняется E2E. TLS защищает от перехвата в пути, но не от доступа на серверах отправителя/получателя.

И ещё: оппортунистический TLS (STARTTLS) может быть подвержен понижению протокола, если дополнительно не приняты меры (см. обсуждение внедрения TLS в межсерверных соединениях у Яндекса и общие проблемы): https://yandex.ru/blog/mail/17481 и https://habr.com/ru/companies/yandex/articles/203882/.


Источники


Заключение

Итог: шифрование почты в Gmail и Yandex.Почте присутствует — TLS защищает передачу, а данные в облаке шифруются на стороне серверов — но это не то же самое, что сквозное (end-to-end) шифрование. Если вам нужно, чтобы только адресат (а не провайдер) мог читать содержимое писем, применяйте S/MIME или PGP/ OpenPGP (или корпоративные клиентские решения в Workspace). Для базовой безопасности и защиты в сети достаточно TLS; для конфиденциальности от самого провайдера нужен именно E2E и корректное управление ключами.

Авторы
Проверено модерацией
Модерация
Сквозное шифрование в Gmail и Yandex.Почте: поддержка?