Почта Mail.ru начинает в тестовом режиме применять политики MTA-STS19.08.2020 12:48

0ceddn37m1f6wcqm3sy52xhcnlm.jpeg

Если кратко, то MTA-STS — это способ дополнительно защитить письма от перехвата (т.е. атак злоумышленник-в-середине aka MitM) при передаче между почтовыми серверами, который частично решает унаследованные архитектурные проблемы протоколов электронной почты, он описан в относительно свежем стандарте RFC 8461. Почта Mail.ru — первая крупная почтовая служба в Рунете, реализующая данный стандарт. А более подробно рассказывается уже под катом.


Исторически, протоколы электронной почты (SMTP, POP3, IMAP) передавали информацию в открытом виде, что позволяет ее перехватывать, например при доступе к каналу связи.

Как выглядит механизм доставки письма от одного пользователя к другому:

uysempd0kt904m_2bf8r7alfsec.png

Исторически, атака MitM была возможна во всех местах, где ходит почта.

Стандарт RFC 8314 требует обязательного использования TLS между почтовой программой пользователя (MUA) и почтовым сервером. Если ваш сервер и используемые почтовые приложения соответствуют RFC 8314, то вы (в значительной мере) устранили возможность атак Man-in-the-Middle между пользователем и почтовыми серверами.

Соблюдение общепринятых практик (стандартизированных RFC 8314) устраняет атаку вблизи пользователя:

a97jxbklxbxisk0kknngqep_go0.png

Почтовые серверы Mail.ru соответствовали RFC 8314 еще до момента принятия стандарта, фактически, он просто фиксирует уже принятые практики, и нам ничего не пришлось настраивать дополнительно. Но, если ваш почтовый сервер все еще пускает пользователей по небезопасным протоколам обязательно реализуйте рекомендации этого стандарта, т.к. скорее всего как минимум часть ваших пользователей работают с почтой без шифрования, даже если вы его поддерживаете.

Почтовый клиент всегда работает с одним и тем же почтовым сервером одной и той же организации. И можно принудительно заставить всех пользователей подключаться безопасным образом, после чего сделать технически невозможным подключаться небезопасным (это как раз и требует RFC 8314). Это иногда сложно, но реализуемо. С трафиком между почтовыми серверами все еще сложней. Серверы принадлежат разным организациям и зачастую используются в режиме «поставил и забыл», что делает невозможным одномоментное переключение на безопасный протокол без нарушения связности. В SMTP уже достаточно давно предусмотрено расширение STARTTLS, позволяющее серверам поддерживающим шифрование переключиться на TLS. Но атакующий, у которого есть возможно влиять на трафик, может «вырезать» информацию о поддержке этой команды и заставить серверы общаться по обычному текстовому протоколу (т.н. downgrade attack — атака на понижение версии протокола). По этой же причине, для STARTTLS обычно не проверяется соответствие сертификата (недоверенный сертификат может защищать от пассивных атак, и это не хуже отправки письма открытым текстом). Поэтому STARTTLS защищает только от пассивной прослушки.

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

Почему частично? MTA-STS работает только если обе стороны позаботились о внедрении этого стандарта, и MTA-STS не защищает от сценариев, при которых у атакующего есть возможность получить валидный сертификат домена в одном из публичных CA.


Получатель

  1. Настраивает поддержку STARTTLS с валидным сертификатом на почтовом сервере. 
  2. Публикует через HTTPS политику MTA-STS, для публикации используется специальный домен mta-sts и специальный well-known путь, например https://mta-sts.mail.ru/.well-known/mta-sts.txt. Политика содержит список почтовых серверов (mx) имеющих право получать почту для этого домена.
  3. Публикует специальную TXT-запись _mta-sts в DNS с версией политики. При изменении политики эта запись должна быть обновлена (это сигнализирует отправителю о необходимости перезапросить политику). Например, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"


Отправитель

Отправитель запрашивает DNS-запись _mta-sts, при ее наличии делает запрос политики по HTTPS (сверяя сертификат). Полученная политика кешируется (на случай, если атакующий блокирует доступ к ней или подменит DNS-запись).

При отправке почты, проверяется что:

  • сервер, на который доставляется почта есть в политике;
  • сервер принимает почту с использованием TLS (STARTTLS) и имеет валидный сертификат.


MTA-STS использует технологии, которые уже внедрены в большинстве организаций (SMTP+STARTTLS, HTTPS, DNS). Для реализации на стороне получателя не требуется специальной программной поддержки стандарта.
Необходимо следить за валидностью сертификата веб и почтового сервера, соответствием имен, своевременным обновлением. Проблемы с сертификатом приведут к невозможности доставить почту.

На стороне отправителя требуется MTA с поддержкой политик MTA-STS, на текущий момент «из коробки» MTA-STS не поддерживается в MTA.

MTA-STS использует список доверенных корневых CA.

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

Два последних пункта делают MTA-STS менее защищенным, чем конкурирующий стандарт DANE для SMTP (RFC 7672), но более технически надежным, т.е. для MTA-STS низка вероятность, что письмо не будет доставлено из-за технических проблем вызванных внедрением стандарта.

Конкурирующий стандарт — DANE


DANE использует DNSSEC для публикации информации о сертификатах и не требует доверия ко внешним удостоверяющим центрам, что гораздо более безопасно. Но использование DNSSEC существенно чаще приводит к техническим сбоям, если опираться на статистику за несколько лет использования (хотя в надежности DNSSEC и его технической поддержки в целом наблюдается положительная динамика). Для реализации DANE в SMTP на стороне получателя наличие DNSSEC для DNS-зоны обязательно, причем для DANE существенна корректная поддержка NSEC/NSEC3, с которой в DNSSEC есть системные проблемы.

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

DANE и MTA-STS не конфликтуют друг с другом и могут быть использованы совместно.


Mail.ru уже достаточно давно публикует политику MTA-STS для всех основных доменов. Сейчас мы занимаемся внедрением клиентской части стандарта. На момент написания статьи, политики применяются в неблокирующем режиме (в случае если доставка блокирована политикой, письмо будет доставлено через «запасной» сервер без применения политик), затем будет форсирован блокирующий режим для небольшой части исходящего SMTP-трафика, постепенно для 100% трафика будет поддерживаться применение политик.
Никак, если ваш домен не публикует политику MTA-STS. Если вы опубликуете политику, то письма для пользователей вашего почтового сервера будут лучше защищены от перехвата.
Поддержка MTA-STS на стороне получателя

Достаточно опубликовать политику через HTTPS и записи в DNS, сконфигурировать валидный сертификат от одного из доверенных CA (можно Let«s encrypt) для STARTTLS в MTA (STARTTLS поддерживается во всех современных MTA), специальной поддержки со стороны MTA не требуется.

По шагам, это выглядит так:

  1. Сконфигурируйте STARTTLS в используемом MTA (postfix, exim, sendmail, Microsoft Exchange и т.д.).
  2. Убедитесь, что используется валидный сертификат (выдан доверенным CA, не просрочен, субъект сертификата соответствует MX-записи, по которой доставляется почта для вашего домена).
  3. Сконфигурируйте TLS-RPT запись, по которой будут доставляться отчеты о применении политик (сервисами поддерживающими отправку отчетов TLS). Пример записи (для домена example.com): 
    smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:tlsrpt@example.com»

    Эта запись инструктирует отправителей почты слать статистические отчеты по использованию TLS в SMTP на адрес tlsrpt@exmple.com.

    Последите за отчетам несколько дней, убедитесь в отсутствии ошибок.

  4. Опубликуйте политику MTA-STS через HTTPS. Политика публикуется как текстовый файл с терминаторами строк CRLF по расположению.
    https://mta-sts.example.com/.well-known/mta-sts.txt

    Пример политики: 
    version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400

    Поле version содержит версию политики (сейчас это STSv1), Mode задает режим применение политики, testing — тестовый режим (политика не применяется), enforce — «боевой» режим. Сначала опубликуйте политику с mode: testing, если с политикой не найдется проблем в тестовом режиме, через некоторое время можно переключиться на mode: enforce.

    В mx задается список всех почтовых серверов, которые могут принимать почту для вашего домена (у каждого сервера должен быть сконфигурирован сертификат, соответствующий имени заданному в mx). Max_age задает время кеширования политики (однажды запомненная политика будет применяться даже если атакующий блокирует ее отдачу или испортит DNS-записи в течение времени кеширования, сигнализировать о необходимости заново запросить политику можно через изменение mta-sts записи DNS).

  5. Опубликуйте в DNS TXT-запись:  
    _mta-sts.example.com. TXT "v=STS1; id=someid;”

    В поле id можно использовать произвольный идентификатор (например метку времени), при изменении политики он должен меняться, это позволяет отправителям понять, что необходимо перезапросить кешированную политику (если идентификатор отличается от кешированного).


Поддержка MTA-STS на стороне отправителя

Пока с ней плохо, т.к. стандарт свежий.


В последнее время регуляторы обращают внимание на безопасность почты (и это хорошо). Например, DMARC обязателен для всех госучреждений в США и все чаще требуется в финансовой сфере, в регулируемых сферах проникновение стандарта достигает 90%. Сейчас некоторые регуляторы требуют внедрения «mandatory TLS» с отдельными доменами, но при этом механизм обеспечения «mandatory TLS» не определяется и на практике эта настройка часто внедряется таким способом, который даже минимально не защищает от реальных атак, которые уже предусмотрены в таких механизмах как DANE или MTA-STS.

Если регулятор требует реализации «mandatory TLS» с отдельными доменами, мы рекомендуем рассмотреть MTA-STS или его частичный аналог как наиболее подходящий механизм, он устраняет необходимость делать безопасные настройки для каждого домена в отдельности. Если у вас есть сложности с реализацией клиентской части MTA-STS (пока протокол не получил широкой поддержки они скорей всего будут), можно рекомендовать такой подход:

  1. Опубликуйте политику MTA-STS и/или записи DANE, это защитит трафик в вашу сторону и избавит от необходимости просить другие почтовые службы настроить mandatory TLS для вашего домена, если почтовая служба уже поддерживает MTA-STS и/или DANE.
  2. Для крупных почтовых сервисов реализуйте «аналог» MTA-STS через отдельные настройки транспорта для каждого домена, которые зафиксируют MX используемый для релеинга почты и будут требовать для него обязательной проверки TLS-сертификата. Если домены уже публикуют политику MTA-STS, это, скорее всего, можно сделать безболезненно. Само по себе включение обязательного TLS для домена без фиксации релея и проверки сертификата для него неэффективно с точки зрения безопасности и ничего не добавляет к имеющимся механизмам STARTTLS.

© Habrahabr.ru