STARTTLS: что это, как работает и чем отличается от implicit TLS

STARTTLS - команда, переключающая уже установленное незашифрованное TCP-соединение на TLS. Она применяется в трёх почтовых протоколах: SMTP (RFC 3207), IMAP (RFC 2595) и POP3 (RFC 2595, команда STLS). Название расшифровывается буквально: «начни TLS» - это инструкция для сервера и клиента провести TLS handshake поверх текущего соединения, после чего весь дальнейший обмен данными идёт по зашифрованному каналу.

STARTTLS не является отдельным протоколом. Это расширение существующих протоколов, позволяющее повысить уровень безопасности без выделения отдельного порта под шифрованное соединение.

Пошаговый процесс в SMTP

Рассмотрим межсерверное соединение на порту 25:

1. Отправляющий MTA устанавливает TCP-соединение с принимающим сервером. Соединение открытое, без шифрования.
2. Принимающий сервер отвечает приветствием: 220 mx.example.com ESMTP.
3. Отправляющий MTA отправляет EHLO и получает список расширений. Среди них - 250-STARTTLS.
4. Отправляющий MTA отправляет команду STARTTLS.
5. Сервер отвечает 220 Ready to start TLS.
6. Обе стороны выполняют TLS handshake: обмениваются сертификатами, согласовывают шифр (например, TLS_AES_256_GCM_SHA384), генерируют сессионные ключи.
7. После успешного handshake клиент повторяет EHLO - уже по зашифрованному каналу. Вся последующая SMTP-сессия (MAIL FROM, RCPT TO, DATA) передаётся в зашифрованном виде.

STARTTLS в IMAP и POP3

Для IMAP (порт 143) клиент отправляет a001 STARTTLS. Сервер отвечает a001 OK Begin TLS negotiation, после чего начинается handshake. Аутентификация (LOGIN или AUTHENTICATE) происходит уже по защищённому каналу.

В POP3 (порт 110) используется команда STLS. Механика идентична: сервер подтверждает готовность, выполняется handshake, затем клиент передаёт USER и PASS по шифрованному каналу.

STARTTLS vs implicit TLS: ключевые различия

• STARTTLS (explicit TLS). Соединение начинается без шифрования на стандартном порту (25, 587, 143, 110). Шифрование активируется после обмена прикладными командами. Между установкой TCP и началом TLS проходит несколько незашифрованных обменов.
• Implicit TLS. Шифрование начинается немедленно при подключении, до обмена прикладными данными. Выделенные порты: 465 (SMTP submissions), 993 (IMAPS), 995 (POP3S). Клиент заранее знает, что на этом порту ожидается TLS.

RFC 8314 (2018) рекомендует implicit TLS для подключений клиент- сервер (MUA-to-MTA) - порты 465, 993, 995. Для межсерверной пересылки (MTA-to-MTA, порт 25) STARTTLS остаётся единственным механизмом, поскольку implicit TLS на порту 25 не стандартизирован.

Opportunistic vs mandatory STARTTLS

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

В mandatory-режиме (enforced) сервер отказывает в доставке при невозможности установить TLS. Это строже, но может заблокировать легитимную почту от отправителей с устаревшими серверами. На практике mandatory STARTTLS применяется в корпоративных сценариях, где обе стороны контролируют свои MTA.

Downgrade-атака: главная уязвимость

Поскольку начало STARTTLS-сессии идёт без шифрования, атакующий на промежуточном сетевом узле (провайдер, Wi-Fi точка, скомпрометированный маршрутизатор) может провести атаку на понижение двумя способами:

• Удаление объявления. Атакующий модифицирует ответ на EHLO, убирая строку 250-STARTTLS. Отправляющий MTA считает, что принимающий не поддерживает TLS, и продолжает без шифрования.
• Подмена ответа. Атакующий перехватывает команду STARTTLS и возвращает клиенту фальшивый код ошибки (например, 502 Command not implemented). Клиент откатывается на нешифрованную передачу.

В обоих случаях пользователь ничего не замечает. Письмо доставляется, но по открытому каналу. Implicit TLS лишён этой проблемы: если handshake не удался, соединение не устанавливается вовсе, и никакие данные не передаются.

Защита: MTA-STS и DANE

Два механизма закрывают уязвимость STARTTLS к downgrade-атакам:

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

Google, Microsoft, Yahoo поддерживают проверку MTA-STS. DANE шире распространён среди европейских провайдеров (Нидерланды, Германия, Чехия), где DNSSEC внедрён на инфраструктурном уровне.

Настройка в Postfix

Для входящих соединений (принимающая сторона):

Значение «may» означает opportunistic: сервер предлагает STARTTLS, но не требует. Значение «encrypt» сделает TLS обязательным.

Для исходящих соединений (отправляющая сторона):

В Dovecot (IMAP/POP3) параметр ssl = yes предлагает STARTTLS, а ssl = required делает его обязательным. Второй вариант рекомендуется для серверов, доступных из интернета.

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

По данным Google Transparency Report, в 2026 году более 96% входящей почты Gmail передаётся через TLS. Google и Yahoo с 2024 года включили TLS в перечень обязательных требований для массовых отправителей. Gmail отображает красный значок незащищённого соединения рядом с письмами, доставленными без TLS.

Для отправителя отсутствие STARTTLS на MTA - потеря доверия и негативный сигнал для спам-фильтров. Настроить его несложно: сертификат Let's Encrypt выпускается за минуту, а конфигурация Postfix занимает четыре строки.