TLS-шифрование email: версии, режимы и настройка

TLS (Transport Layer Security) - криптографический протокол, который создаёт зашифрованный канал между двумя сетевыми узлами. В email TLS применяется в двух направлениях: между почтовыми серверами при пересылке писем (MTA-to-MTA) и между почтовым клиентом пользователя и сервером (MUA-to-MTA). Без TLS содержимое писем, включая логины и пароли, передаётся открытым текстом и может быть перехвачено на любом промежуточном узле.

SSL и TLS: краткая история

SSL (Secure Sockets Layer) - предшественник TLS, разработанный Netscape. SSL 2.0 вышел в 1995 году, SSL 3.0 - в 1996. В 1999 году IETF выпустил TLS 1.0 (RFC 2246), который по сути являлся переработкой SSL 3.0 с устранением ряда уязвимостей.

Все версии SSL и TLS 1.0/1.1 официально объявлены устаревшими (RFC 8996, 2021). В 2026 году в промышленной эксплуатации остаются TLS 1.2 (RFC 5246) и TLS 1.3 (RFC 8446). Термин «SSL» продолжает встречаться в интерфейсах почтовых клиентов, но фактически за ним стоит TLS.

Что именно защищает TLS

TLS обеспечивает три свойства для данных в транзите:

• Конфиденциальность. Данные зашифрованы симметричным ключом (AES-GCM, ChaCha20-Poly1305). Третья сторона не может прочитать содержимое.
• Целостность. MAC (message authentication code) или AEAD-шифрование гарантирует, что данные не были изменены при передаче.
• Аутентификация сервера. Сертификат X.509 подтверждает, что клиент подключился к настоящему серверу, а не к подставному.

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

Два режима подключения

• STARTTLS (explicit TLS). Клиент подключается к стандартному порту (25 для SMTP, 143 для IMAP, 110 для POP3) без шифрования. После обмена приветствиями отправляет команду STARTTLS. Если сервер поддерживает её, обе стороны выполняют TLS handshake и переключаются на зашифрованный канал.
• Implicit TLS. Шифрование начинается сразу при подключении, до любого обмена данными. Используются выделенные порты: 465 (SMTP), 993 (IMAP), 995 (POP3). RFC 8314 (2018) рекомендует implicit TLS для подключений клиент-сервер.

Opportunistic vs enforced TLS

При межсерверной пересылке (порт 25) TLS обычно работает в режиме opportunistic. Отправляющий MTA проверяет, поддерживает ли принимающий STARTTLS. Если да - устанавливается зашифрованное соединение. Если нет - письмо передаётся открытым текстом. Это компромисс: лучше доставить незашифрованное письмо, чем не доставить вовсе.

Enforced TLS (принудительный режим) отказывает в доставке при невозможности установить шифрование. Применяется в корпоративных сценариях, где обе стороны заранее договорились о требованиях к безопасности.

Проблема downgrade-атак

Opportunistic TLS уязвим к атаке на понижение (downgrade). Атакующий на промежуточном узле может модифицировать ответ сервера, удалив из него объявление STARTTLS. Отправляющий MTA решит, что шифрование недоступно, и передаст письмо открытым текстом. Для пользователя это незаметно.

Два механизма противодействуют этой атаке:

• MTA-STS (RFC 8461) - домен публикует политику через HTTPS-файл, указывая, что его MX-серверы требуют TLS. Отправляющий MTA кэширует политику и отказывается переключаться на нешифрованную передачу. Дополняется TLS-RPT (RFC 8460) для отчётов о неудачных подключениях.
• DANE (RFC 7672) - использует DNSSEC-подписанные записи TLSA для привязки сертификата к домену. Более надёжный механизм, но требует внедрения DNSSEC, что ограничивает распространение.

TLS 1.2 vs TLS 1.3

TLS 1.3 (2018) - текущая версия протокола. Основные отличия от 1.2:

• Handshake выполняется за один round-trip вместо двух. Для повторных соединений возможен 0-RTT (нулевая задержка).
• Удалены слабые алгоритмы: RSA key exchange, CBC-mode ciphers, SHA-1, RC4, DES, 3DES. Остались только AEAD-шифры.
• Forward secrecy обязателен. Каждая сессия использует уникальный эфемерный ключ (ECDHE или DHE).

Для почтовых серверов переход на TLS 1.3 даёт ускорение handshake (меньше задержка при установке соединения) и исключение устаревших шифров. Большинство современных MTA (Postfix 3.4+, Exim 4.93+) поддерживают TLS 1.3 при наличии OpenSSL 1.1.1 и выше.

Проверка TLS-конфигурации

Несколько способов убедиться, что TLS настроен корректно:

• Google Postmaster Tools - показывает долю входящей и исходящей почты, переданной через TLS. Значение ниже 95% - повод разобраться.
• CheckTLS.com - проверяет, поддерживает ли MX-сервер STARTTLS, какие версии TLS и шифры доступны, валиден ли сертификат.
• openssl s_client - подключение вручную из командной строки. Позволяет проверить сертификат, цепочку доверия, версию TLS и согласованный шифр.

TLS и доставляемость

Gmail отображает красный значок незащищённого соединения рядом с письмами, доставленными без TLS. Это заметно снижает доверие получателя. Кроме визуального предупреждения, отсутствие TLS - один из негативных сигналов для спам-фильтров. В 2026 году легитимный отправитель без TLS - исключение, которое вызывает подозрение.

Google и Yahoo с 2024 года требуют TLS для массовых рассылок как обязательное условие. Письма, доставленные без шифрования, рискуют попасть в спам или быть отклонёнными.