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

Какъв проблем решава 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

получател

1. Конфигурира поддръжката на STARTTLS с валиден сертификат на пощенския сървър. 
2. Публикува MTA-STS политиката чрез HTTPS; специален домейн mta-sts и специален добре известен път се използват за публикуване, например 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

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 е от съществено значение за DANE, с които има системни проблеми в DNSSEC.

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

DANE и MTA-STS не са в конфликт помежду си и могат да се използват заедно.

Какво става с поддръжката на MTA-STS в Mail.ru Mail?

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

Кой друг поддържа стандарта?

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

Как ще ми се отрази това?

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

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

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

Достатъчно е да публикувате политиката чрез HTTPS и записи в DNS, да конфигурирате валиден сертификат от един от доверените CA (Нека шифроването е възможно) за 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:[email protected]»

   Този запис инструктира подателите на поща да изпращат статистически отчети за използването на TLS в SMTP до [email protected].

   Следете отчетите няколко дни, за да се уверите, че няма грешки.

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
   

   Полето версия съдържа версията на политиката (в момента STSv1), режимът задава режима на прилагане на политиката, тестване — тестов режим (политиката не се прилага), прилагане — „боен“ режим. Първо публикувайте политиката с режим: тестване, ако няма проблеми с политиката в тестов режим, след известно време можете да превключите на режим: прилагане.

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

5. Публикуване на TXT запис в DNS: 

   _mta-sts.example.com. TXT “v=STS1; id=someid;”
   

   Можете да използвате произволен идентификатор (например клеймо за време) в полето за id; когато политиката се промени, тя трябва да се промени, това позволява на подателите да разберат, че трябва да поискат повторно кешираната политика (ако идентификаторът е различен от кеширан).

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

Засега е зле с нея, защото... свеж стандарт.

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

Като послеслов за „задължителен TLS“

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

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

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

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