MTA-STS — это предложенный стандарт RFC8461, вышедший из статуса черновика и официально опубликованный 26 сентября 2018 года. Этот стандарт предлагает механизм обнаружения возможности для использования полноценного TLS между почтовыми серверами, с шифрованием данных и аутентификацией сервера. То есть, этот стандарт практически полностью защищает от вмешательства в почтовый трафик между серверами.
Упрощённо, суть стандарта в следующем:
Существуют неплохие статьи (например), рассказывающие про сам стандарт и для чего он нужен, сравнивающие MTA-STS с другими аналогичными инициативами, и даже показывающие как составить и опубликовать политику. Но найти, как продвинуться дальше первого шага, оказалось не так-то просто.
Перед внедрением MTA-STS необходимо привести в порядок сертификаты почтового сервера. В противном случае, почтовые серверы, принимающие во внимание вашу политику STS, будут отвергать соединение с вашим сервером. Должны быть выполнены следующие условия:
Проверить настроенный сервер с сертификатом можно следующей командой:
где MX.EXAMPLE.COM — доменное имя вашего MX-сервера. Для полного соответствия со стандартом желательно проверить, что нужное доменное имя присутствует не только в Common Name сертификата, но как минимум в Subject Alternative Name.
Для того, чтобы обозначить ваш домен как поддерживающий безопасное соединение с ним, нужно опубликовать политику MTA-STS. Для этого нужно выполнить следующие несложные действия в указанном порядке (примеры приведёны для домена example.com).
1. Разместить по адресу
текстовый файл вида:
Файл обязательно должен отдаваться с Content-Type: text/plain. Редиректы не допускаются. Переводы строк должны быть либо LF, либо CRLF. Пустые строки не допускаются. Последняя строка может быть окончена переводом строки, либо может быть не окончена им — допускаются оба варианта. Пустое пространство перед двоеточием и в начале строки не допускается. Пустое пространство после двоеточия допускается в любом количестве. Пустое пространство (пробелы, табуляция и т.д.) в конце каждой строки игнорируется.
Значения полей:
version: версия формата. Всегда должна быть равна «STSv1».
mode: режим политики. Возможные варианты: none, testing, enforce. Режим enforce соответствует нормальному функционированию стандарта — требовать при подключении к серверу правильный сертификат и стойкое TLS-соединение. Режим testing требует пытаться использовать безопасное соединение, но в случае ошибки отправлять почту в любом случае с уведомлением администратора через механизм TLSRPT. Режим none соответствует такому положению вещей, как если бы политика не была опубликована вовсе. Этот режим полезен для правильного отключения политики.
mx: одно или несколько полей, содержащих имена всех разрешённых MX-серверов домена. Как видно из примера, допускаются шаблоны, но только в качестве домена нижнего уровня.
max_age: время в секундах, на которое политика может быть кэширована и в течение которого отправители могу продолжать ее использовать, если политика перестала быть доступной. Из-за этого свойства стандарта отключение STS быстрее проводить публикацией новой политики с режимом none.
2. Создать TXT-запись _mta-sts.example.com с содержимым вида:
Пробельные символы вокруг точки с запятой могут быть расставлены произвольно в любом количестве. В остальных местах пробельные символы не допускаются. Последняя точка с запятой может как присутствовать, так и отсутствовать.
Значения полей:
v: версия формата. Всегда должно быть первым полем, всегда должно быть равно STSv1.
id: уникальный идентификатор опубликованной политики. Может быть строкой длиной 1-32 символа, состоящей из букв обоих регистров и цифр. Изменение значения id является сигналом для отправителей о том, что политика обновилась. Поэтому обновление политики нужно проводить сначала публикуй новый файл политики, а затем меняя id в TXT-записи.
С этого момента почтовые серверы, поддерживающие MTA-STS, будут отправлять почту в ваш домен только через безопасное соединение с проверкой подлинности сертификата. На этом большинство руководств заканчивается, но впереди как раз самое интересное — добиться от собственного сервера соблюдения политики MTA-STS при отправке почты.
Основная трудность заключается в том, что этот стандарт не поддерживается почтовыми серверами, в том числе Postfix. Однако, эта неприятная мелочь не должна нас останавливать.
Поиск решения привёл меня к архиву почтовой рассылки postfix-users с обсуждением сроков реализации этого стандарта. В одном из сообщений Витсе Венема, автор Postfix, указывает на предпочтительное направление для реализации этого функционала — использовать внешний сервер для поиска политик TLS. Предлагается использование директивы конфигурации вида:
Я реализовал такой сервер для получения политики MTA-STS.
→ Исходный код
→ Пакет в PyPI
Приложению не достаёт некоторых функций, которые предписывает RFC8461, таких как: упреждающее получение политики, отчёты и ограничение частоты запросов политики. Однако, основную функцию — обнаружение политики TLS и её кэширование — оно выполняет.
Приложение требует Python 3.5.3+. Установка и настройка этого демона может быть проведена посредством следующих шагов.
Достаточно выполнить команду:
Об альтернативных способах установки написано здесь.
Если Вас устраивают настройки по умолчанию, то достаточно команды
В ином случае конфигурацию можно взять из примера и подстроить её под свои нужды.
Наиболее важный параметр, на мой взгляд — параметр strict_testing. Если он установлен в true (по умолчанию false), то приложение будет возвращать secure policy даже для доменов, с политикой в режиме testing. Такое поведение против стандарта, но целесообразно из практических соображений: если владелец домена опубликовал STS-политику даже в режиме тестирования, то он наверняка готов к ней. То есть тогда уже сегодня почта на gmail.com отправится по надёжному соединению.
В случае с systemd достаточно разместить простой unit-файл в /etc/systemd/system/mta-sts-daemon.service
После этого остаётся перечитать конфигурацию systemd, включить автозапуск демона и запустить его:
Подразумевая, что используется порт по умолчанию, команда
должна вывести
Добавьте строку в main.cf:
Перезагрузите Postfix:
Если всё сделано верно, то для STS-соединений в логе /var/log/mail.info вместо
начнут появляться записи
Если вы дошли до этого места, это скорее всего означает:
Упрощённо, суть стандарта в следующем:
- Поддерживающие его почтовые сервисы публикуют политику (1 TXT-запись и 1 HTTPS-ресурс для каждого домена).
- Почтовые сервисы при отправке почты в другие домены производят обнаружение политики домена-получателя.
- Почтовые сервисы соединяются с почтовым сервером домена-получателя, применяя ограничения к TLS, задаваемые обнаруженной политикой, если таковая нашлась.
Существуют неплохие статьи (например), рассказывающие про сам стандарт и для чего он нужен, сравнивающие MTA-STS с другими аналогичными инициативами, и даже показывающие как составить и опубликовать политику. Но найти, как продвинуться дальше первого шага, оказалось не так-то просто.
Начнём сначала
Перед внедрением MTA-STS необходимо привести в порядок сертификаты почтового сервера. В противном случае, почтовые серверы, принимающие во внимание вашу политику STS, будут отвергать соединение с вашим сервером. Должны быть выполнены следующие условия:
- Сертификат сервера выпущен общепризнанным удостоверяющим центром (Let's Encrypt годится).
- Цепочка сертификатов, отправляемая сервером, включает все необходимые сертификаты промежуточных удостоверяющих центров.
- Сертификат имеет поле Subject Alternative Name с DNS-именем вашего MX-сервера.
Проверить настроенный сервер с сертификатом можно следующей командой:
[ "$(LANG=C openssl s_client -connect MX.EXAMPLE.COM:25 -starttls smtp -verify_hostname MX.EXAMPLE.COM < /dev/null 2>&1 | fgrep 'error')" = "" ] && echo OK || echo FAILгде MX.EXAMPLE.COM — доменное имя вашего MX-сервера. Для полного соответствия со стандартом желательно проверить, что нужное доменное имя присутствует не только в Common Name сертификата, но как минимум в Subject Alternative Name.
Публикация политики
Для того, чтобы обозначить ваш домен как поддерживающий безопасное соединение с ним, нужно опубликовать политику MTA-STS. Для этого нужно выполнить следующие несложные действия в указанном порядке (примеры приведёны для домена example.com).
1. Разместить по адресу
https://mta-sts.example.com/.well-known/mta-sts.txt
текстовый файл вида:
version: STSv1 mode: enforce mx: mail.example.com mx: *.example.net mx: backupmx.example.com max_age: 604800
Файл обязательно должен отдаваться с Content-Type: text/plain. Редиректы не допускаются. Переводы строк должны быть либо LF, либо CRLF. Пустые строки не допускаются. Последняя строка может быть окончена переводом строки, либо может быть не окончена им — допускаются оба варианта. Пустое пространство перед двоеточием и в начале строки не допускается. Пустое пространство после двоеточия допускается в любом количестве. Пустое пространство (пробелы, табуляция и т.д.) в конце каждой строки игнорируется.
Значения полей:
version: версия формата. Всегда должна быть равна «STSv1».
mode: режим политики. Возможные варианты: none, testing, enforce. Режим enforce соответствует нормальному функционированию стандарта — требовать при подключении к серверу правильный сертификат и стойкое TLS-соединение. Режим testing требует пытаться использовать безопасное соединение, но в случае ошибки отправлять почту в любом случае с уведомлением администратора через механизм TLSRPT. Режим none соответствует такому положению вещей, как если бы политика не была опубликована вовсе. Этот режим полезен для правильного отключения политики.
mx: одно или несколько полей, содержащих имена всех разрешённых MX-серверов домена. Как видно из примера, допускаются шаблоны, но только в качестве домена нижнего уровня.
max_age: время в секундах, на которое политика может быть кэширована и в течение которого отправители могу продолжать ее использовать, если политика перестала быть доступной. Из-за этого свойства стандарта отключение STS быстрее проводить публикацией новой политики с режимом none.
2. Создать TXT-запись _mta-sts.example.com с содержимым вида:
v=STSv1; id=20160831085700Z;
Пробельные символы вокруг точки с запятой могут быть расставлены произвольно в любом количестве. В остальных местах пробельные символы не допускаются. Последняя точка с запятой может как присутствовать, так и отсутствовать.
Значения полей:
v: версия формата. Всегда должно быть первым полем, всегда должно быть равно STSv1.
id: уникальный идентификатор опубликованной политики. Может быть строкой длиной 1-32 символа, состоящей из букв обоих регистров и цифр. Изменение значения id является сигналом для отправителей о том, что политика обновилась. Поэтому обновление политики нужно проводить сначала публикуй новый файл политики, а затем меняя id в TXT-записи.
С этого момента почтовые серверы, поддерживающие MTA-STS, будут отправлять почту в ваш домен только через безопасное соединение с проверкой подлинности сертификата. На этом большинство руководств заканчивается, но впереди как раз самое интересное — добиться от собственного сервера соблюдения политики MTA-STS при отправке почты.
Самое интересное
Основная трудность заключается в том, что этот стандарт не поддерживается почтовыми серверами, в том числе Postfix. Однако, эта неприятная мелочь не должна нас останавливать.
Поиск решения привёл меня к архиву почтовой рассылки postfix-users с обсуждением сроков реализации этого стандарта. В одном из сообщений Витсе Венема, автор Postfix, указывает на предпочтительное направление для реализации этого функционала — использовать внешний сервер для поиска политик TLS. Предлагается использование директивы конфигурации вида:
smtp_policy_maps = socketmap:inet:host:port:name
Я реализовал такой сервер для получения политики MTA-STS.
→ Исходный код
→ Пакет в PyPI
Приложению не достаёт некоторых функций, которые предписывает RFC8461, таких как: упреждающее получение политики, отчёты и ограничение частоты запросов политики. Однако, основную функцию — обнаружение политики TLS и её кэширование — оно выполняет.
Приложение требует Python 3.5.3+. Установка и настройка этого демона может быть проведена посредством следующих шагов.
Установка пакета
Достаточно выполнить команду:
pip3 install postfix-mta-sts-resolverОб альтернативных способах установки написано здесь.
Создание конфигурационного файла
Если Вас устраивают настройки по умолчанию, то достаточно команды
touch /etc/postfix/mta-sts-daemon.ymlВ ином случае конфигурацию можно взять из примера и подстроить её под свои нужды.
Наиболее важный параметр, на мой взгляд — параметр strict_testing. Если он установлен в true (по умолчанию false), то приложение будет возвращать secure policy даже для доменов, с политикой в режиме testing. Такое поведение против стандарта, но целесообразно из практических соображений: если владелец домена опубликовал STS-политику даже в режиме тестирования, то он наверняка готов к ней. То есть тогда уже сегодня почта на gmail.com отправится по надёжному соединению.
Организация автозапуска
В случае с systemd достаточно разместить простой unit-файл в /etc/systemd/system/mta-sts-daemon.service
После этого остаётся перечитать конфигурацию systemd, включить автозапуск демона и запустить его:
systemctl daemon-reload
systemctl enable mta-sts-daemon.service
systemctl start mta-sts-daemon.serviceПроверка работоспособности
Подразумевая, что используется порт по умолчанию, команда
/usr/sbin/postmap -q dismail.de socketmap:inet:127.0.0.1:8461:postfixдолжна вывести
secure match=mx1.dismail.de
Подключение к Postfix
Добавьте строку в main.cf:
smtp_policy_maps = socketmap:inet:127.0.0.1:8461:postfixПерезагрузите Postfix:
systemctl reload postfix.serviceЕсли всё сделано верно, то для STS-соединений в логе /var/log/mail.info вместо
Trusted TLS connection established
начнут появляться записи
Verified TLS connection established
Заключение
Если вы дошли до этого места, это скорее всего означает:
- Вы прочитали статью без единой картинки.
- День ото дня вероятность перехвата почты вашего домена будет падать, по мере того как остальные почтовые сервисы реализуют новый стандарт.
