MTA-STS, DANE и TLS-RPT: обязательный TLS для почты

Почта между серверами обычно шифруется, но ничто этого не гарантирует. Отправляющий сервер подключается к вашему MX на порт 25, видит предложение STARTTLS и повышает соединение - если только что-то на пути не уберёт это предложение, и тогда он пожмёт плечами и отправит письмо открытым текстом. Кроме того, он не проверяет, что показанный ему сертификат принадлежит вашему серверу. Это оппортунистический TLS: он останавливает пассивное прослушивание и больше ничего. Закрывают эту брешь три стандарта. MTA-STS публикует по HTTPS политику, в которой сказано: «мои почтовые серверы называются так-то, и TLS у них всегда действительный». DANE публикует отпечаток сертификата в DNS, подписанном DNSSEC. TLS-RPT просит отправителей сообщать вам, когда TLS до вас не сработал. Для большинства доменов правильный первый шаг - TLS-RPT плюс MTA-STS в тестовом режиме с переходом на enforce после нескольких недель чистых отчётов; DANE имеет смысл, если ваш DNS-провайдер нормально поддерживает DNSSEC.

Как STARTTLS работает между почтовыми серверами и где он ломается#

SMTP-сеанс между двумя серверами начинается открытым текстом. Принимающий сервер в ответ на EHLO перечисляет свои возможности, и если среди них есть STARTTLS, отправитель может попросить повышения:

S: 220 mail.example.com ESMTPC: EHLO mx.sender.netS: 250-mail.example.comS: 250-SIZE 52428800S: 250-STARTTLSS: 250 ENHANCEDSTATUSCODESC: STARTTLSS: 220 2.0.0 Ready to start TLS

Всё после этого зашифровано. Слабые места - в двух решениях, которые принимает отправитель:

• Повышать ли соединение. Список возможностей передаётся открытым текстом. Злоумышленник на пути - или плохо ведущий себя файрвол, который «инспектирует» SMTP, а такое действительно бывает, - может вырезать строку 250-STARTTLS. Отправитель видит сервер, не предлагающий TLS, и доставляет письмо открытым текстом, потому что отказ означал бы отказ в доставке на множество серверов, которые действительно не поддерживают TLS.
• Доверять ли сертификату. Даже с TLS у отправителя нет надёжного способа узнать, какое имя должно быть в сертификате. Запись MX пришла из неаутентифицированного DNS, поэтому злоумышленник, способный подделать DNS, может направить отправителя на собственный сервер с собственным действительным сертификатом. Поэтому большинство отправителей принимают любой сертификат, включая самоподписанные и просроченные.

Оппортунистический TLS всё равно полезен - он срывает массовый пассивный сбор данных, - но против активного злоумышленника ничего не делает. MTA-STS и DANE решают обе проблемы, давая отправителю заранее опубликованное аутентифицированное заявление о том, чего ожидать.

MTA-STS: политика, опубликованная по HTTPS#

У MTA-STS (RFC 8461) две части: DNS-запись TXT, сообщающая, что политика существует, и сама политика, загружаемая по HTTPS с фиксированного адреса. Поскольку HTTPS опирается на обычную систему веб-сертификатов, политика аутентифицирована, хотя сам DNS-запрос - нет.

Отправитель запрашивает _mta-sts.example.com, находит id, загружает https://mta-sts.example.com/.well-known/mta-sts.txt и кэширует политику на max_age секунд. С этого момента каждая доставка на ваш домен должна идти на хост MX, соответствующий политике, по TLS и с сертификатом, который действителен для этого имени хоста и выстраивается в цепочку до публичного удостоверяющего центра. В режиме enforce отправитель, который не может выполнить эти условия, письмо не доставляет; оно ждёт в его очереди и отправляется повторно.

Устойчивость к атакам обеспечивает именно кэш. Злоумышленник, заблокировавший загрузку политики при одной из следующих доставок, ничего не добьётся, потому что у отправителя всё ещё есть политика с прошлого раза. Слабый момент - первый контакт, поэтому max_age обычно делают большим.

Публикация политики MTA-STS#

Нужны три вещи: файл политики, веб-сервер, который отдаёт его с действительным сертификатом по адресу mta-sts.<ваш домен>, и запись TXT.

Файл политики:

version: STSv1mode: testingmx: mail.example.commax_age: 86400

Запись TXT:

v=STSv1; id=20261008T120000

id - любая строка длиной до 32 букв и цифр. Отправители сравнивают её с закэшированной и загружают политику заново, когда она меняется, поэтому удобнее всего использовать метку времени. Каждый раз, когда вы правите файл политики, меняйте id.

Правила, которые спецификация делает строгими и на которые приходится большинство сломанных внедрений:

1. У хоста политики должен быть действительный сертификат для mta-sts.example.com, выпущенный публичным центром. Самоподписанный не подойдёт - на этом держится всё доверие.
2. Никаких перенаправлений. При загрузке политики отправители не должны следовать HTTP-перенаправлениям. Веб-сервер, который перенаправляет /.well-known/... на другой путь или хост, молча ломает MTA-STS.
3. Отдавайте файл как `text/plain` с ответом 200.
4. Каждая строка `mx` должна совпадать с именами в ваших записях MX, а сертификат на каждом почтовом сервере должен быть действителен для имени, на которое указывает MX.

Начните с mode: testing и короткого max_age, например в сутки. В тестовом режиме отправители доставляют почту в любом случае, но сообщают о сбоях через TLS-RPT. После двух-трёх недель отчётов, где нет ничего, кроме успехов, переключитесь на enforce, поднимите max_age до недели или больше (604800) и смените id.

TLS-RPT: как узнать, что TLS не сработал#

TLS-RPT (RFC 8460) - это ещё одна запись TXT. Она просит отправителей присылать вам ежедневную сводку их TLS-соединений с вашим доменом:

v=TLSRPTv1; rua=mailto:tls-reports@example.com

Крупные отправители, включая Google и Microsoft, такие отчёты присылают. Каждый - это сжатый gzip JSON-документ за один день: какая политика применялась (MTA-STS, DANE или никакой), число успешных сеансов и число сбоев по типам. Типы сбоев достаточно конкретны, чтобы по ним действовать:

Публикуйте TLS-RPT раньше всего остального, даже без MTA-STS. Без политики отчёты всё равно покажут, сколько отправителей достучались до вас по TLS, а это полезная отправная точка, и стоят они ничего. Заведите для них отдельный почтовый ящик - они приходят ежедневно от каждого крупного провайдера - и либо читайте JSON сами, либо загружайте его в один из бесплатных просмотрщиков отчётов.

DANE: сертификаты, закреплённые в DNSSEC#

DANE для SMTP (RFC 7672) идёт к той же цели другим путём. Вместо политики по HTTPS вы публикуете запись TLSA, где указано, какой сертификат или ключ предъявляет ваш почтовый сервер, а доверие к записи обеспечивается тем, что зона подписана DNSSEC.

_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 (    8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d )

Три числа - это usage, selector и matching type. 3 1 1 - «вот этот конкретный ключ конечного сертификата, по его хешу SHA-256» - распространённая и рекомендуемая для почты форма: она вообще не зависит ни от какого удостоверяющего центра, и самоподписанный сертификат допустим. Хеш берётся от открытого ключа сертификата, и его можно вычислить из файла сертификата:

$ openssl x509 -in cert.pem -noout -pubkey \    | openssl pkey -pubin -outform DER \    | openssl dgst -sha256

У DANE два жёстких требования, и они решают, подходит ли он вам:

• Зона, где находятся имена хостов `MX`, должна быть подписана DNSSEC, как и зона вашего домена, чтобы запросу MX можно было доверять. Если ваш DNS-провайдер не предлагает DNSSEC или вы не уверены, что справитесь с ним, на этом остановитесь. Сломанная цепочка DNSSEC вредит больше, чем просто отключённый DANE: проверяющие резолверы вообще перестают разрешать домен.
• Смену ключа нужно планировать. Поскольку запись закрепляет ключ, если продлить сертификат с новым ключом, не обновив сначала запись, каждый отправитель, проверяющий DANE, откажется доставлять почту. Либо используйте при продлении тот же ключ (у большинства ACME-клиентов есть такая опция), либо опубликуйте хеш нового ключа рядом со старым, дождитесь истечения TTL записи, затем смените сертификат и уберите старый хеш.

DANE проверяют, среди прочих, Postfix и Exim при соответствующей настройке, Stalwart для исходящей почты и Exchange Online от Microsoft. Gmail вместо этого опирается на MTA-STS. Из-за такого разделения многие администраторы публикуют и то и другое.

MTA-STS или DANE

Если можете сделать только что-то одно, для небольшого домена MTA-STS - более простой и более широко соблюдаемый вариант. Если у вашего DNS-провайдера DNSSEC включается одной галочкой, а со сменой ключей вы дисциплинированны, добавьте DANE. Они сосуществуют без конфликтов, и TLS-RPT отчитывается по обоим.

Сторона отправки: ваш сервер и чужие домены#

Всё описанное выше защищает почту, отправленную вам. Ваш собственный сервер, когда отправляет, принимает те же решения в отношении чужих доменов. Stalwart при доставке исходящей почты проверяет политики MTA-STS и записи DANE, и и то и другое настраивается для каждой стратегии доставки в веб-админке. По умолчанию они считаются необязательными: опубликованная и действительная политика применяется, но домен, чью политику не удаётся загрузить или проверить, почту всё равно получает. Если глобально перевести любой из них в «require», ваш сервер откажется доставлять почту на множество доменов, которые не публикуют ни того ни другого, а это не то, что вам нужно. Оставьте значения по умолчанию, если только у вас нет конкретного партнёрского домена, где шифрование должно быть гарантировано, - и для него заведите отдельное правило.

Как это сделать на почтовом сервере RE:NODE#

Линейка Mail Server работает на Stalwart, а DNS-записи здесь - TXT для MTA-STS и TLS-RPT, TLSA для DANE - вы добавляете сами у того, кто обслуживает ваш DNS, так же как записи MX, SPF, DKIM и DMARC. Поддержка перенаправляет порт 25 на сервер, чтобы он мог принимать почту из интернета, и именно этот порт проверяют отправители, применяя вашу политику, поэтому, прежде чем что-то публиковать, убедитесь, что предъявляемый там сертификат покрывает имя, на которое указывает ваш MX.

Файлу политики MTA-STS нужен веб-хостинг с действительным сертификатом на mta-sts.example.com. Подойдёт любой статический хостинг. На тарифе веб-хостинга направьте запись A для mta-sts.example.com на адрес, указанный для слота прокси, и сертификат будет выпускаться и продлеваться автоматически; политика - это один текстовый файл в .well-known. Проверьте, что ничто в конфигурации сайта не перенаправляет этот путь.

Порядок действий, при котором почта не теряется#

Эти записи лежат поверх тех, которые нужны любому почтовому домену, так что сначала проверьте фундамент. SPF, DKIM и DMARC решают, поверят ли вашей почте; MX-записи решают, куда почта пойдёт. Политика TLS описывает лишь то, как она туда доберётся, и политика, написанная под неправильный MX, хуже, чем никакой.

1. Исправьте сертификат на порту 25. Он должен быть действительным, не просроченным и покрывать все имена, на которые указывают ваши записи MX. Пока это не так, каждый следующий шаг будет приносить отчёты о сбоях.
2. Опубликуйте TLS-RPT. Соберите неделю отчётов вообще без политики, чтобы увидеть, как отправители достучиваются до вас сейчас.
3. Опубликуйте MTA-STS в тестовом режиме с max_age в одни сутки. Читайте отчёты две-три недели.
4. Переключитесь на enforce, поднимите max_age, смените id. Продолжайте читать отчёты: продление, которое не удастся через три месяца, первым делом проявится там.
5. Добавляйте DANE, только если ваш DNS подписан DNSSEC и у вас есть записанный план смены ключей.

Привычка та же, что делает безопасным внедрение DMARC: публикуйте в режиме отчётов, читайте, что приходит, и только потом требуйте, - подробнее это описано в статье отчёты DMARC и поэтапное внедрение политики. Агрегированные отчёты - единственная обратная связь, которую вы получаете от чужих почтовых серверов, и они стоят отдельного почтового ящика, который им нужен.

Проверка настройки#

С любой машины, где есть dig, curl и openssl:

$ dig +short TXT _mta-sts.example.com$ curl -sv https://mta-sts.example.com/.well-known/mta-sts.txt$ dig +short TXT _smtp._tls.example.com$ dig +short MX example.com$ openssl s_client -connect mail.example.com:25 -starttls smtp \    -servername mail.example.com </dev/null | openssl x509 -noout -subject -dates$ dig +dnssec +short TLSA _25._tcp.mail.example.com

Проверьте, что загрузка политики возвращает 200 без перенаправления, что строки mx совпадают с ответом MX, что сертификат на порту 25 называет хост MX и не просрочен, и - для DANE - что ответ TLSA совпадает с хешем ключа, а ответ прошёл проверку. Продление сертификатов, на котором большинство таких настроек рано или поздно и ломается, описано в статье ваш домен и его сертификат.

FAQ#

Шифруется ли моя почта без всего этого?

Обычно да. Большинство крупных провайдеров предлагают и используют STARTTLS, поэтому почти вся почта идёт в зашифрованном виде. Без MTA-STS или DANE у вас нет лишь гарантии: злоумышленник, способный вмешаться в соединение или в DNS, может принудить к открытому тексту или выдать себя за ваш сервер, и отправитель этого не заметит.

Шифрует ли MTA-STS почту, которую я отправляю другим людям?

Нет. Ваша политика говорит другим серверам, как доставлять почту вам. Защищена ли ваша исходящая почта, зависит от того, публикует ли политику домен получателя и соблюдает ли её ваш сервер. Stalwart при отправке применяет записи MTA-STS и DANE чужих доменов.

Что будет, если моя политика в режиме enforce окажется неверной?

Отправители, которые её соблюдают, откажутся доставлять почту и будут держать её в очереди, обычно несколько дней, прежде чем вернуть её исходному отправителю. До вас ничего не дойдёт, и ничто вам об этом не сообщит, кроме отчётов TLS-RPT. Вот почему сначала идёт тестовый режим и почему изменение политики требует нового id.

Нужен ли DNSSEC для MTA-STS?

Нет. MTA-STS создавался для доменов без DNSSEC; доверие к нему обеспечивает HTTPS-сертификат на хосте политики. DNSSEC требуется как раз для DANE.

Каким должен быть max_age?

Сутки на время тестирования, чтобы ошибки быстро истекали. После перехода на enforce и стабилизации обычно ставят от недели до месяца, а более долгий срок лучше защищает от злоумышленника, блокирующего загрузку политики. Помните, что большой max_age означает и долгое ожидание, когда вы меняете почтовые серверы.