02.10.2018 08:41
YourChief 17 824 Источник
MTA-STS — это предложенный стандарт RFC8461, вышедший из статуса черновика и официально опубликованный 26 сентября 2018 года. Этот стандарт предлагает механизм обнаружения возможности для использования полноценного TLS между почтовыми серверами, с шифрованием данных и аутентификацией сервера. То есть, этот стандарт практически полностью защищает от вмешательства в почтовый трафик между серверами.

Упрощённо, суть стандарта в следующем:

  1. Поддерживающие его почтовые сервисы публикуют политику (1 TXT-запись и 1 HTTPS-ресурс для каждого домена).
  2. Почтовые сервисы при отправке почты в другие домены производят обнаружение политики домена-получателя.
  3. Почтовые сервисы соединяются с почтовым сервером домена-получателя, применяя ограничения к 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


Заключение


Если вы дошли до этого места, это скорее всего означает:

  • Вы прочитали статью без единой картинки.
  • День ото дня вероятность перехвата почты вашего домена будет падать, по мере того как остальные почтовые сервисы реализуют новый стандарт.

Комментарии (17)


  1. elve
    02.10.2018 14:27
    #19182985

    Чтобы добавить безопасности (TLS) надо сделать потенциальную дыру (web-сервер). Почему нельзя было как с DKIM и SPF сделать анонсирование целиком в DNS?


    1. YourChief Автор
      02.10.2018 14:50
      #19183059

      The primary motivation of MTA-STS is to provide a mechanism for
      domains to ensure transport security even when deploying DNSSEC is
      undesirable or impractical.

      Потому что DNS-ответы не защищены и могут быть перехвачены так же, как сами соединения — такой стандарт ничего бы не добавил в отношении безопасности.


      1. elve
        02.10.2018 15:04
        #19183111

        Так все равно же есть TXT-запись. И запрос также можно перехватить и подменить. Как минимум можно «выключить» нужному серверу шифрование.

        В чем тогда профит лишнего сервиса?


        1. YourChief Автор
          02.10.2018 15:54
          #19183321

          По стандарту отсутствие TXT-записи при наличии валидной закэшированной политики не является достаточным основанием, чтобы выключить шифрование. Моя реализация это отражает. Кэширование политики пролонгируется каждый раз, когда получена TXT-запись с той же версией политики.
          Действительно, если атакующий предотвратит первоначальное получение политики, либо будет срывать обновление политики вплоть до истечения срока действия политики, то ему удастся осуществить даунгрэйд.
          По этому поводу написано следующее:

          1. Желательно выбирать как можно большее время кэширования политики max_age.
          2. Нужно оповещать администраторов о срывах обновления политики при наличии действующей политики.
          3. DANE обладает сопротивляемостью к таким атакам.

          То есть с первоначальным обнаружением политики вопрос никак не решаем в рамках стандарта. Однако, если домен-получатель использует DNSSEC, а отправитель использует DNSSEC-совместимый резолвер, то и такой проблемы не будет — не важно, с DANE или с MTA-STS.


          1. elve
            02.10.2018 16:36
            #19183495

            Т.е. без использования dnssec нет гарантии работоспособности mta-sts. А при использовании dnssec данные из него будут достоверными и можно в нем всю информацию хранить. И мы приходим к изначальному вопросу — так зачем в этой схеме лишний веб-сервер? =)


            1. YourChief Автор
              02.10.2018 18:01
              #19183875

              Затем, что без него можно подделать все ответы, а с ним можно подделать только отрицание наличия политики и только тогда, когда у отправителя нет никакой политики в кэше. Это позволяет трактовать отсутствие подлинной политики после «первого» получения как проблему. Схема с одной DNS-записью этого не позволяет, так как не различает подлинность какого бы то ни было ответа.
              P.S. Всё сказанное относится к ситуации, в которой отсутствует DNSSEC, для которой стандарт и разработан.


              1. elve
                02.10.2018 19:34
                #19184171

                Можно еще подменить веб-сервер. И ваш сервер по окончании кэша втянет в себя некую новую политику =). Все та же TXT-запись на DNS-сервере, которому доверять нельзя =).
                Получается, что по факту доверять mta-sts нельзя, пока мы все не перелезли на dnssec. А если dnssec доверять можно, то зачем нам веб-сервер? =).

                Хотя тут вопрос поинтереснее — зачем нам такой mta-sts и есть ли смысл ради него поднимать дополнительный потенциально уязвимый сервис? Даже два. Некая служба на питоне (можно конечно проверить код, но кто ж это делает в реальности? =) ) и веб-сервер.


                1. YourChief Автор
                  02.10.2018 19:45
                  #19184225

                  Можно еще подменить веб-сервер.

                  Вот с этого места поподробнее, пожалуйста.


                  1. elve
                    02.10.2018 21:26
                    #19184565

                    Раз мы можем редактировать ответы DNS-сервера, то почему бы не подменить А-запись для mta-sts.example.com? Там будет файл с нашей политикой.


                    1. YourChief Автор
                      02.10.2018 22:30
                      #19184767

                      Подмена A-записи и любой другой перехват соединения не дают возможности обмануть HTTPS-клиента и выдать себя за другой HTTPS-сервер. Для этого необходимо обладать валидным сертификатом и приватным ключом от него. Советую ознакомиться с тем, как работает HTTPS и TLS.

                      Хотя тут вопрос поинтереснее — зачем нам такой mta-sts и есть ли смысл ради него поднимать дополнительный потенциально уязвимый сервис? Даже два.

                      Это вопрос из другой плоскости. Рассуждения из серии: стоит ли делать прививки, если есть вероятность, что шприц грязный. Каждый отвечает на этот вопрос по-своему, однако к стандарту в этом смысле претензий нет: он предписывает забирать данные по простому и широкораспространённому протоколу, который уже десятилетия имеет зрелые реализации.

                      Что же касается моего демона — по умолчанию он недоступен снаружи, так как занимает сокет на loopback-адресе 127.0.0.1. Присоединиться к этому порту снаружи не даст система — даже файрвол не нужен. Тот факт, что он написан на питоне в смысле безопасности даже плюс, так как это избавляет от массы проблем с нативными языками: переполнения буфера, ошибки при работе с указателями и так далее.

                      По поводу того, кто проверяет код. Например, я. На хабре я уже публиковал статью про анализ исходника, который вызвал у меня сомнения. Была и моя статья даже про анализ бинарного кода с целью снятия ограничений. Так что это не какой-то космос.


                      1. elve
                        03.10.2018 06:45
                        #19185441

                        Так мы же подменяем ответы DNS-сервера =). Letsencrypt запросто сгенерит нам новый валидный сертификат ).


                        1. YourChief Автор
                          03.10.2018 11:21
                          #19186067

                          Учите матчасть. Если вы вклинитесь в чьё-то интернет-подключение, то подмените DNS только для него, не для всего интернета.


                          1. elve
                            03.10.2018 12:34
                            #19186435

                            Т.е. вы считаете что только такой вид атаки возможен и на основе этого считаете меня неграмотным? =). А как вам редактирование трафика DNS-сервера?
                            Если мы присаживаемся на канал вашего почтовика (но не dns-сервера), то можем отключить шифрование между вашим сервером и каким-то другим, для вашей исходящей почты. Они то будут знать через dns, что вы шифруете трафик и к вам будут ломиться на правильный порт.
                            Но ведь это не единственный возможный вариант. Я вижу еще к примеру такой:
                            Если мы присаживаемся на канал DNS-сервера (а именно это я и подразумеваю в случае тотального недоверия dns), то мы можем отключить входящее шифрование ото всех =). И, если ваш почтовик пользуется вашим же dns-сервером, то и исходящее тоже ).

                            В итоге, если мы не доверяем DNS, то целесообразность mta-sts для меня не ясна. А если доверяем DNS, то можно все запихнуть в TXT-запись =).


                            1. YourChief Автор
                              03.10.2018 16:05
                              #19187497

                              Т.е. вы считаете что только такой вид атаки возможен и на основе этого считаете меня неграмотным? =)

                              Сразу два приёма демагога в одном предложении: переход к выводам, основанный на ложной посылке.

                              Речь шла о перехвате трафика между почтовыми серверами. Вы заявили, что можно угнать HTTPS-трафик сервера политик на другой сервер. Подмена A-записи в этой коммуникации ничего не даёт. Возможность выпустить сертификат возникает только при угоне доменной зоны, в том числе через вмешательство в трафик авторитативного DNS-сервера. В этом случае речь о «подмене веб-сервера mta-sts.example.com» уже не идёт. Это просто не нужно, так как уже можно выпустить валидный сертификат сразу MX-сервера и MTA-STS тут ни при чём: перехват будет осуществим даже если бы все и всегда форсировали использование TLS для обмена.
                              В сухом остатке: ваша «подмена на веб-сервера» несостоятельна, она требует фактического обладания доменом, при котором можно диктовать практически всё.

                              А как вам редактирование трафика DNS-сервера?

                              И, если ваш почтовик пользуется вашим же dns-сервером, то и исходящее тоже

                              Вообще из этих всех рассуждений неясно, о каком именно DNS-сервере идёт речь. В контексте про выпуск серта речь может идти только про авторитативный. В контексте про сервер, которым пользуется другой сервер, речь скорее всего идёт про рекурсивный резолвер (например 8.8.8.8).

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

                              В итоге, если мы не доверяем DNS, то целесообразность mta-sts для меня не ясна. А если доверяем DNS, то можно все запихнуть в TXT-запись =).

                              Это очередной демагогический приём, в котором суждение про потенциально возможный угон домена обобщается на вообще любой перехват DNS и исходя из этого устанавливается ложная эквивалентность между достоверностью данных, получаемыми прямо из DNS и через HTTPS.
                              Разница ясна — переписать DNS-ответы по пути может любой Вася, а чтобы вскрыть HTTPS надо установить контроль над доменом, выпустить серт (что само по себе палевно). И, как я говорил выше, при таком раскладе уже неважно всё остальное.


                              1. elve
                                03.10.2018 18:31
                                #19188243

                                Получается что условный Вася может читать нашу входящую почту, а условный агент Смит всю =).

                                Стоит ли игра свеч? Чем эта суета лучше варианта, который использует гугл? Недавно обнаружил, что почта с гмыла не приходит. Оказалось что гугл сразу цепляется по ssl =).


                                1. YourChief Автор
                                  03.10.2018 18:47
                                  #19188367

                                  Недавно обнаружил, что почта с гмыла не приходит. Оказалось что гугл сразу цепляется по ssl =).


                                  Я вчера-позавчера проверял то же самое — у меня получилось, что почта с гугла приходит даже когда сертификат не соответстует по хостнейму. При том, что у меня опубликована политика enforce (у гмайла политика testing).

                                  У outlook.com есть TXT-запись, но не скачивается политика. Сертификаты на SMTP-серверах вообще стоят от балды.

                                  Интересно, что это всё компании, принимавшие участие в создании стандарта.


  1. Sleuthhound
    03.10.2018 19:32
    #19188557
    +1

    Хорошая статья, автору респект, но было бы круто, если бы Вы переписали вашу программу с питона на golang, чтобы она была автономной и независимой.