TLS 1.3 и cipher suites для Postfix и Dovecot: как получить A+ и не сломать доставку
Большинство TLS-гайдов для почты — карго-культ: копируют строку из блога 2016 года и ждут A+. Разбираем три отдельные TLS-поверхности почтового сервера, настраиваем submission и IMAP до A+ на testssl.sh и объясняем, почему на входящем MX затягивать шифры до TLS 1.3-only — прямой путь к потере писем.
EvilMail Team23 июля 2026 г.11 мин чтения
Откройте любой гайд «как настроить TLS в Postfix» — с вероятностью 90% там будет одна строка smtpd_tls_mandatory_protocols = TLSv1.2, скопированная из поста 2016 года, и подпись «теперь у вас безопасная почта». Это не безопасность, это ритуал. И хуже того: если вы честно попробуете «запретить всё слабое» разом на всех портах, A+ вы не получите. Вы получите отбойники от легаси-серверов и часть входящего трафика открытым текстом.
Корень в том, что у почтового сервера не одна TLS-поверхность, а три, и жить они должны по разным правилам. SMTP на порту 25 — оппортунистический TLS: отправляющий сервер сам решает, шифровать или нет, и если ваши шифры ему не подошли, он не переспросит — он отправит письмо открытым текстом или упадёт с ошибкой. А submission (587/465) и IMAP/POP (993/995) — аутентифицированные каналы с вашими собственными клиентами, где условия диктуете вы. Смешивать их политику нельзя.
Три TLS-поверхности, которые нельзя настраивать одинаково
Разложим по полкам — дальше вся статья держится на этом разделении:
MX, порт 25 — входящий SMTP от чужих серверов. TLS здесь may (оппортунистический). Ваша задача — не отпугнуть отправителя. TLS 1.3-only здесь запрещён.
Postfix и Dovecot TLS 1.3: cipher suites, ECDHE и оценка A+ — EvilMail Blog
MSA, порты 587 (STARTTLS) и 465 (implicit TLS) — отправка от ваших аутентифицированных пользователей. TLS обязателен (encrypt), и здесь мы гоним до A+.
IMAP/POP3S, порты 993/995 (Dovecot) — доступ к ящикам. Тоже ваши клиенты, тоже A+, и здесь реально можно уйти в TLS 1.3-only.
Сначала измеряем — и не браузером
Браузер и Qualys SSL Labs здесь бесполезны: серверный тест Qualys ходит только на 443, STARTTLS на submission он не умеет и порт 587 вам не проверит. Рабочий инструмент — testssl.sh, плюс Immuniweb для второго мнения.
bash
# submission через STARTTLS
testssl.sh --starttls smtp mail.evilmail.pro:587
# implicit TLS submission
testssl.sh mail.evilmail.pro:465
# IMAPS
testssl.sh mail.evilmail.pro:993
# входящий MX — тут смотрим не grade, а факт наличия PFS и отсутствия SSLv3/TLSv1
testssl.sh --starttls smtp mail.evilmail.pro:25
Читаем вывод по трём осям: Protocols (на 587/993 не должно быть TLS 1.0/1.1), блок Cipher order (должен стоять серверный приоритет) и раздел уязвимостей — SWEET32, 3DES, LUCKY13, небезопасный renegotiation. A+ требует ровно этого: только TLS 1.2+, каждый suite с forward secrecy, серверное предпочтение шифров, полная валидная цепочка сертификата.
Postfix: submission на 587/465 — затягиваем
Это ваш главный кандидат на A+. В master.cf сервисы submission и smtps должны переопределять политику через -o, чтобы жёсткость касалась только клиентов, а не входящего MX:
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_mandatory_protocols=>=TLSv1.2
-o smtpd_tls_protocols=>=TLSv1.2
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
smtps inet n - y - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_mandatory_protocols=>=TLSv1.2
-o smtpd_sasl_auth_enable=yes
А глобальные параметры шифров живут в main.cf:
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
tls_preempt_cipherlist = yes
smtpd_tls_eecdh_grade = auto
tls_preempt_cipherlist = yes — это и есть «серверное предпочтение шифров», без которого testssl.sh не поставит A+, даже если список идеален. smtpd_tls_eecdh_grade = auto даёт Postfix выбрать между P-256 и P-384.
Здесь же — самая частая ловушка, о которую разбиваются часы отладки. TLS 1.3-шифры не управляются через `tls_high_cipherlist`. Три suite версии 1.3 — TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256 — OpenSSL 1.1.1+ настраивает отдельным механизмом (ciphersuites), и Postfix не даёт их переопределять. Это не баг и не дыра: все три считаются безопасными, forward secrecy у каждого встроен в протокол. Если вы видите их в выводе testssl.sh и пытаетесь «убрать лишнее» через cipherlist — остановитесь, вы правите не тот параметр.
Postfix: MX на порту 25 — намеренно оставляем TLS 1.2
Здесь начинается прагматика, которую гайды стыдливо обходят. Глобально в main.cf:
may означает: предложи TLS, но если у отправителя ничего не сложилось — прими письмо открытым текстом. Звучит как капитуляция, но альтернатива хуже. Поставьте на порт 25 encrypt или TLS 1.3-only — и часть легитимных отправителей (корпоративные шлюзы, госсерверы, старые appliance) просто не смогут вам доставить почту. В оппортунистическом SMTP нет фолбэка на «давай послабее»: не совпало — либо plaintext, либо bounce.
Поэтому на входящем канале настоящая защита — не рейтинг шифров, а аутентификация самого TLS: DANE (запись TLSA в DNS под DNSSEC) и MTA-STS с политикой enforce плюс отчётность через TLS-RPT. Они заставляют отправителя проверять ваш сертификат и запрещают downgrade — то, чего оппортунистический TLS сам по себе не гарантирует. Гнаться за A+ на порту 25 бессмысленно: его туда всё равно никто не пойдёт мерить, а сломать доставку — реально.
Dovecot: IMAP/POP3S — самый жёсткий режим
Здесь клиенты только ваши, значит закручиваем максимально. /etc/dovecot/conf.d/10-ssl.conf:
ssl_min_protocol в Dovecot делает больше, чем гора OpenSSL-магии: одной строкой он отсекает целые классы атак на старые протоколы. Если в вашей базе нет клиентов на Windows 7 и древнем Outlook, ставьте ssl_min_protocol = TLSv1.3 — и IMAP уходит в 1.3-only, где downgrade-атаки на обмен ключами невозможны по устройству протокола. Для IMAP это безопаснее, чем для SMTP, потому что клиент под вашим контролем: не подключился старый Thunderbird — обновили Thunderbird, а не порвали федеративную доставку.
Важная деталь версий: в Dovecot 2.3+ параметр называется ssl_dh и указывает на файл, а не старый ssl_dh_parameters_length. DH-группу генерируем руками один раз:
bash
openssl dhparam -out /etc/dovecot/dh.pem 4096
ECDHE и forward secrecy — то, за что реально дают A+
Ключевое слово во всех cipherlist выше — ECDHE. Именно эфемерный обмен ключами (Elliptic Curve Diffie-Hellman Ephemeral, а в TLS 1.3 — X25519) даёт forward secrecy: сессионный ключ рождается на лету и нигде не хранится. Скомпрометируют завтра приватный ключ сервера — весь перехваченный ранее трафик всё равно останется нечитаемым, потому что для расшифровки нужен эфемерный ключ, которого уже не существует. Статический RSA-обмен ключами такого не даёт: один украденный ключ раскрывает всю историю. В TLS 1.3 RSA-key-exchange вырезан из протокола в принципе — ephemeral обязателен.
Практический вывод: список кривых ssl_curve_list = X25519:prime256v1:secp384r1 ставит X25519 первым не случайно — это самый быстрый и самый устойчивый вариант обмена. А smtpd_tls_eecdh_grade = auto в Postfix делает то же самое со стороны SMTP.
Сертификат, цепочка и OCSP
A+ не дадут за голый leaf-сертификат — нужна полная цепочка (leaf + intermediate) в одном файле. У Let's Encrypt это fullchain.pem. Хотите ускорить handshake — поднимите dual-cert: ECDSA P-256 как основной (короче ключ, быстрее подпись) плюс RSA как запасной для древних клиентов. В Postfix это два набора в smtpd_tls_chain_files.
Отдельная боль — обновление сертификата. Certbot по умолчанию не перезагружает демоны, и через 90 дней вы начинаете отдавать протухший сертификат. Deploy-hook лечит:
4.testssl.sh --starttls smtp mail.evilmail.pro:587 → ждём grade A+, отсутствие TLS 1.0/1.1, PFS на всех suite, нет SWEET32/3DES.
5.testssl.sh mail.evilmail.pro:993 → то же для IMAP.
6.Реальный клиент: подключить Thunderbird/Outlook по 587 и 993, убедиться, что отправка и получение живы.
7.posttls-finger -c -l encrypt smtp:mail.example.com:25 — проверить исходящий handshake с диагностикой к внешнему MX.
8.grep "TLS library problem" /var/log/mail.log — пусто. Появилась эта строка после reload — значит кто-то из клиентов упёрся в шифр или протокол, который вы отрезали; разберитесь, кто именно, прежде чем оставлять настройку.
Разделяйте поверхности, меряйте testssl.sh, а не браузером, и держите в голове главное различие: submission и IMAP затягиваете до упора, а порт 25 защищаете DANE и MTA-STS, а не рейтингом шифров. Тогда A+ окажется там, где его реально проверяют, а входящая почта продолжит доходить.
