Накратко, MTA-STS е начин за допълнителна защита на имейлите от перехват (т.е. атаки на злонамерени лица в средата aka MitM) при предаване между имейл сървъри. Той частично решава наследените архитектурни проблеми на имейл протоколите и е описан в относително новия стандарт RFC 8461. Mail.ru е първата голяма имейл услуга в Рунета, която реализира този стандарт. А по-подробно ще бъде разказано по-долу.

Какъв проблем решава MTA-STS?

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

Как изглежда механизмът на доставка на писмо от един потребител на друг:

Исторически, атака MitM беше възможна на всяко място, където преминава имейл.

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

Спазването на общоприетите практики (стандартизирани RFC 8314) елиминира атаката в близост до потребителя:

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

Почтовият клиент винаги работи с един и същ пощенски сървър на същата организация. Може принудително да накарате всички потребители да се свързват по безопасен начин, след което да направите технически невъзможно свързването по незащитен (това точно изисква RFC 8314). Понякога е сложно, но осъществимо. С трафика между пощенските сървъри е все по-трудно. Сървърите принадлежат на различни организации и често се използват в режим „постави и забрави“, което прави невъзможно едновременното преминаване на безопасен протокол без нарушение на свързаността. В SMTP от доста време е предвидено разширение STARTTLS, позволяващо на сървърите, които поддържат криптиране, да преминат на TLS. Но нападател, който има възможност да влияе на трафика, може да „изреже“ информацията за поддръжката на тази команда и да накара сървърите да комуникират чрез обикновен текстови протокол (т.н. атака по понижаване на версията на протокола). По същата причина, за STARTTLS обикновено не се проверява валидността на сертификата (недоверен сертификат може да защитава от пасивни атаки и това не е по-лошо от изпращането на имейл в открит текст). Следователно, STARTTLS защитава само от пасивно подслушване.

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

Защо частично? MTA-STS работи само ако двете страни са се погрижили да внедрят този стандарт и MTA-STS не защитава при сценарии, при които нападателят има възможност да получи валиден сертификат за домейн от един от публичните CA.

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

Получателят

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

Изпращач

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

При изпращане на поща се проверява дали:

сървърът, на който се доставя пощата, е в политиката;
сървърът приема поща с използване на TLS (STARTTLS) и има валиден сертификат.

Предимства на MTA-STS

MTA-STS използва технологии, които вече са внедрени в повечето организации (SMTP+STARTTLS, HTTPS, DNS). За реализиране от страна на получателя не се изисква специална софтуерна поддръжка на стандарта.

Недостатъци на MTA-STS

Необходимо е да се следи валидността на сертификата на уеб и пощенския сървър, приспособлението на имената и навременните обновления. Проблеми с сертификата ще доведат до невъзможност за доставяне на пощата.

От страна на изпращача е необходим 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-зоната е задължително, като е особено важно правилното поддържане на NSEC/NSEC3, с което има системни проблеми в DNSSEC.

Ако DNSSEC е конфигуриран с грешки, това може да доведе до откази при доставката на имейли, ако изпращащата страна поддържа DANE, дори ако получаващата страна нищо не знае за него. Затова, въпреки че DANE е по-стар и защитен стандарт и вече е поддържан в някои сървърни софтуерни приложения от страна на изпращача, фактически внедряването му остава незначително, много организации не са готови да го внедрят поради необходимостта от настройка на DNSSEC, което значително забавя внедряването на DANE през всички години, в които стандартът съществува.

DANE и MTA-STS не си противоречат и могат да бъдат използвани заедно.

Каква е подкрепата за MTA-STS в пощата Mail.ru

Mail.ru отдавна публикува политика MTA-STS за всички основни домейни. В момента работим по внедряване на клиентската част от стандарта. Към момента на написване на статията, политиките се прилагат в неблокиращ режим (в случай, че доставката е блокирана от политиката, писмото ще бъде доставено чрез „резервен“ сървър без прилагане на политиките), след това ще бъде наложен блокиращ режим за малка част от изходящия SMTP трафик, постепенно 100% от трафика ще поддържа прилагане на политиките.

Кои още поддържат стандарта

Към момента политиките MTA-STS публикуват около 0.05% от активните домейни, но все пак те вече защитават голям обем от пощенския трафик, тъй като стандартът се поддържа от големи играчи — Google, Comcast и частично Verizon (AOL, Yahoo). Много други пощенски услуги обявиха, че поддръжката на стандарта ще бъде реализирана в близко бъдеще.

Как това ще ме засегне?

Никак, ако вашият домейн не публикува политика MTA-STS. Ако публикувате политика, то имейлите за потребителите на вашия пощенски сървър ще бъдат по-добре защитени от прихващане.

Как да внедря MTA-STS?

Поддръжка на MTA-STS от страна на получателя

Достатъчно е да публикувате политика чрез HTTPS и DNS записи, да конфигурирате валиден сертификат от един от доверените CA (може Let’s Encrypt) за STARTTLS в MTA (STARTTLS се поддържа от всички съвременни MTA), специална поддръжка от страна на MTA не е необходима.

Стъпка по стъпка, това изглежда така:

Конфигурирайте STARTTLS в използвания MTA (postfix, exim, sendmail, Microsoft Exchange и т.н.).
Убедете се, че се използва валиден сертификат (издаден от доверен CA, не е изтекъл, субектът на сертификата съответства на MX записа, по който се доставя пощата за вашия домейн).
Конфигурирайте TLS-RPT записа, по който ще се доставят отчетите за прилагане на политиките (с услугите, поддържащи изпращане на отчети TLS). Пример на записа (за домейн example.com):
```
smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"
```
Тази записка инструктира изпращачите на имейли да изпращат статистически отчети за използването на TLS в SMTP на адреса tlsrpt@exmple.com.
Следете отчетите в продължение на няколко дни, уверете се, че няма грешки.
Публикувайте политиката 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).
Публикувайте в DNS TXT запис:
```
_mta-sts.example.com. TXT "v=STS1; id=someid;"
```
В полето id можете да използвате произволен идентификатор (например времеви печат), при промяна на политиката той трябва да се променя, което позволява на изпращачите да разберат, че е необходимо да се повтори запитването за кешираната политика (ако идентификаторът се различава от кешираната).

Поддръжка на MTA-STS от страна на изпращача

За момента ситуацията не е добра, тъй като стандартът е нов.

Exim — няма вградена поддръжка, има външен скрипт https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix — няма вградена поддръжка, има външен скрипт, за който подробно е описано в Хабра https://habr.com/en/post/424961/

В заключение относно «задължителния TLS»

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

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

Публикувайте политиката MTA-STS и/или записите DANE (DANE има смисъл да се добавя само ако вашият домейн вече има активиран DNSSEC, а MTA-STS в какъвто и да е случай), това ще защити трафика към вас и ще ви освободи от необходимостта да искате от други пощенски служби да настроят задължителен TLS за вашия домейн, ако пощенската служба вече поддържа MTA-STS и/или DANE.
За големите пощенски услуги реализирайте "аналог" на MTA-STS чрез отделни настройки на транспорта за всеки домейн, които ще фиксират MX, използван за реле на пощата и ще изискват задължителна проверка на TLS сертификата. Ако домените вече публикуват политика MTA-STS, това вероятно може да се направи безболезнено. Самото включване на задължителен TLS за домейн без фиксация на релея и проверка на сертификата за него е неефективно от гледна точка на сигурността и не добавя нищо към съществуващите механизми STARTTLS.

Източник: habr.com