MTA-STS и TLS-RPT: как сделать шифрование почты обязательным

Когда почтовые серверы передают друг другу письма, они обычно пытаются установить шифрованное соединение через STARTTLS. Но это шифрование необязательное: если кто-то посередине вырежет предложение STARTTLS или подсунет поддельный сертификат, отправляющий сервер чаще всего просто отправит письмо открытым текстом. В итоге договоры, счета и персональные данные могут передаваться без защиты. Стандарт MTA-STS закрывает эту брешь: он сообщает отправляющим серверам, что доставлять почту на ваш домен можно только по шифрованному соединению с действительным сертификатом. А TLS-RPT присылает вам отчёты о проблемах, возникших в этом процессе.

Как работает MTA-STS

MTA-STS состоит из двух частей. Первая — небольшая TXT-запись в DNS, сообщающая, что у домена есть политика, и указывающая её текущую версию. Вторая — файл политики, размещённый по HTTPS, где перечислены допустимые MX-серверы и указано, насколько строгой должна быть проверка. Отправляющий сервер сначала видит DNS-запись, затем скачивает файл политики и кеширует его на определённый срок. После этого при отправке писем на ваш домен он проверяет, что сертификат MX-сервера действителен и имя совпадает.

Важно, что файл политики загружается именно по HTTPS. Подделать ответ DNS сравнительно легко, а подделать веб-страницу, защищённую действительным сертификатом, гораздо сложнее. Поэтому MTA-STS не требует DNSSEC и на практике доступен для внедрения почти любому домену.

Проверка MX-серверов перед началом

MTA-STS работает только если у MX-серверов правильные сертификаты: выданные доверенным центром, с неистёкшим сроком и с именем, совпадающим с именем в MX-записи. Если включить режим enforce при самоподписанном сертификате или сертификате на другое имя, письма перестанут доставляться. Для проверки сначала получите MX-записи, затем попробуйте STARTTLS-соединение с каждым сервером:

dig +short MX example.uz
openssl s_client -starttls smtp -connect mail.example.uz:25 -servername mail.example.uz </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

В выводе видно, на кого выписан сертификат, кто его выдал и срок действия. Если почта размещена на серверах хостинг-провайдера, уточните у провайдера имя MX и состояние сертификата: именно это имя будет указано в файле политики. В некоторых сетях исходящий порт 25 закрыт, тогда выполняйте проверку с сервера или из другой сети.

Размещение файла политики

Файл политики должен лежать на поддомене mta-sts по строго заданному пути: https://mta-sts.example.uz/.well-known/mta-sts.txt. Для этого поддомену нужны DNS-запись и действительный SSL-сертификат. Содержимое файла — простой текст, по одному параметру в строке:

version: STSv1
mode: testing
mx: mail.example.uz
mx: mail2.example.uz
max_age: 604800

У параметра mode три значения: в режиме testing отправители лишь сообщают о проблеме в отчётах и всё равно доставляют письмо, в режиме enforce письмо не отправляется, если требования к шифрованию не выполнены, а none используется для отмены политики. max_age задаётся в секундах и определяет срок кеширования; значение выше соответствует одной неделе. Если имена MX находятся под общим доменом, можно использовать шаблон вида mx: *.example.uz.

Если поддомен обслуживает Nginx, для выдачи файла достаточно такого блока:

server {
    listen 443 ssl;
    server_name mta-sts.example.uz;
    ssl_certificate     /etc/letsencrypt/live/mta-sts.example.uz/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.example.uz/privkey.pem;

    location = /.well-known/mta-sts.txt {
        default_type text/plain;
        alias /var/www/mta-sts/mta-sts.txt;
    }
}

На обычном хостинге достаточно создать поддомен mta-sts как отдельный сайт, создать в его папке каталог .well-known и положить туда файл.

DNS-записи MTA-STS и TLS-RPT

Когда файл готов, добавляются две TXT-записи. Первая объявляет о наличии политики MTA-STS и содержит значение id — метку версии политики. При каждом изменении файла id нужно обновлять, иначе отправители продолжат пользоваться старой закешированной политикой. Обычно в качестве id пишут дату и время. Вторая запись относится к TLS-RPT и указывает адрес для отчётов.

_mta-sts.example.uz.    IN  TXT  "v=STSv1; id=20261104T090000"
_smtp._tls.example.uz.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.uz"

Проверьте всё следующими командами: файл политики должен открываться, а DNS-записи — отображаться:

curl -s https://mta-sts.example.uz/.well-known/mta-sts.txt
dig +short TXT _mta-sts.example.uz
dig +short TXT _smtp._tls.example.uz

Чтение отчётов TLS-RPT

Провайдеры, поддерживающие TLS-RPT, обычно раз в сутки присылают отчёт в формате JSON. В нём указано, сколько шифрованных сеансов с вашим доменом прошло успешно, сколько завершилось ошибкой и по какой причине. Среди причин — истёкший сертификат, несовпадение имени или отсутствие STARTTLS. В режиме testing именно эти отчёты показывают, безопасно ли переходить на enforce. Если неделю-две ошибок нет, можно сменить режим в файле политики и обновить id.

Пример: аудиторская компания в Ташкенте

Аудиторская компания в Ташкенте получает от клиентов финансовую отчётность и договоры по электронной почте. Руководство беспокоится, что эти данные могут передаваться без шифрования. Администратор сначала убеждается, что у MX-сервера действительный сертификат, затем создаёт поддомен mta-sts, размещает файл политики в режиме testing и добавляет обе TXT-записи. За две недели в отчётах TLS-RPT нет неудачных сеансов. После этого режим меняют на enforce, обновляют id, и провайдеры, поддерживающие политику, доставляют почту компании только по защищённому соединению.

На что обратить внимание

Самая частая ошибка — забыть обновить файл политики при смене MX-сервера. Если нового имени MX нет в файле, а режим enforce, отправители не смогут доставить почту. Поэтому перед переездом почты добавьте новое имя в файл, обновите id и дождитесь истечения срока кеша. Вторая ошибка — истёкший сертификат на поддомене mta-sts: тогда новая политика не загружается. Проблему решает автоматически продлеваемый сертификат. На хостинге sayt.uz бесплатные сертификаты Let's Encrypt для поддоменов продлеваются автоматически, так что о сертификате поддомена mta-sts отдельно беспокоиться не нужно.