Укратко, МТА-СТС је начин за даљу заштиту е-поште од пресретања (тј. напада човека у средини ака МитМ) када се преносе између сервера поште. Делимично решава старе архитектонске проблеме протокола е-поште и описан је у релативно недавном стандарду РФЦ 8461. Маил.ру је први велики сервис поште на РуНету који примењује овај стандард. И то је детаљније описано под резом.
Који проблем решава МТА-СТС?
Историјски гледано, протоколи е-поште (СМТП, ПОП3, ИМАП) су преносили информације у чистом тексту, што је омогућавало њихово пресретање, на пример, када се приступа неком комуникацијском каналу.
Како изгледа механизам за достављање писма од једног корисника другом:
Историјски гледано, МитМ напад је био могућ на свим местима где пошта циркулише.
РФЦ 8314 захтева употребу ТЛС-а између апликације корисника поште (МУА) и сервера поште. Ако су ваш сервер и апликације за пошту које користите у складу са РФЦ 8314, онда сте (у великој мери) елиминисали могућност напада човека у средини између корисника и сервера поште.
Праћење опште прихваћене праксе (стандардизовано РФЦ 8314) елиминише напад у близини корисника:
Маил.ру сервери поште били су у складу са РФЦ 8314 чак и пре него што је стандард усвојен, он једноставно обухвата већ прихваћене праксе и нисмо морали ништа додатно да конфигуришемо. Али, ако ваш сервер за пошту и даље дозвољава корисницима да користе небезбедне протоколе, обавезно примените препоруке овог стандарда, јер Највероватније, бар неки од ваших корисника раде са поштом без шифровања, чак и ако то подржавате.
Клијент поште увек ради са истим сервером поште исте организације. И можете да натерате све кориснике да се повежу на безбедан начин, а затим да технички онемогућите повезивање небезбедних корисника (то је управо оно што захтева РФЦ 8314). Ово је понекад тешко, али изводљиво. Саобраћај између сервера поште је још компликованији. Сервери припадају различитим организацијама и често се користе у режиму „подеси и заборави“, што онемогућава прелазак на безбедан протокол одједном без прекида везе. СМТП већ дуго обезбеђује СТАРТТЛС екстензију, која омогућава серверима који подржавају шифровање да пређу на ТЛС. Али нападач који има могућност да утиче на саобраћај може „изрезати“ информације о подршци за ову команду и натерати сервере да комуницирају коришћењем протокола обичног текста (тзв. напад на нижу верзију). Из истог разлога, СТАРТТЛС обично не проверава валидност сертификата (непоуздани сертификат може заштитити од пасивних напада, а то није ништа горе од слања поруке у чистом тексту). Стога, СТАРТТЛС штити само од пасивног прислушкивања.
МТА-СТС делимично елиминише проблем пресретања писама између сервера поште, када нападач има могућност да активно утиче на саобраћај. Ако домен примаоца објави МТА-СТС политику, а сервер пошиљаоца подржава МТА-СТС, он ће послати е-пошту само преко ТЛС везе, само на сервере дефинисане политиком и само уз верификацију сертификата сервера.
Зашто делимично? МТА-СТС функционише само ако су обе стране водиле рачуна о примени овог стандарда, а МТА-СТС не штити од сценарија у којима нападач може да добије важећи сертификат домена од једног од јавних ЦА.
Како функционише МТА-СТС
прималац
- Конфигурише СТАРТТЛС подршку са важећим сертификатом на серверу поште.
- Објављује политику МТА-СТС преко ХТТПС-а, на пример, за објављивање се користи посебан мта-стс домен и посебна добро позната путања
https://mta-sts.mail.ru/.well-known/mta-sts.txt. Политика садржи листу сервера поште (мк) који имају право да примају пошту за овај домен. - Објављује посебан ТКСТ запис _мта-стс у ДНС-у са верзијом политике. Када се политика промени, овај унос се мора ажурирати (ово сигнализира пошиљаоцу да поново постави упит за политику). На пример,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Сендер
Пошиљалац захтева _мта-стс ДНС запис, и ако је доступан, поставља захтев за политику преко ХТТПС-а (провера сертификата). Резултирајућа политика се кешује (у случају да јој нападач блокира приступ или лажира ДНС запис).
Приликом слања поште проверава се да:
- сервер на који се испоручује пошта је у политици;
- сервер прихвата пошту користећи ТЛС (СТАРТТЛС) и има важећи сертификат.
Предности МТА-СТС
МТА-СТС користи технологије које су већ имплементиране у већини организација (СМТП+СТАРТТЛС, ХТТПС, ДНС). За имплементацију на страни примаоца није потребна посебна софтверска подршка за стандард.
Недостаци МТА-СТС
Неопходно је пратити валидност сертификата веб и маил сервера, подударност имена и благовремено обнављање. Проблеми са сертификатом ће довести до тога да пошта неће бити у могућности да буде испоручена.
На страни пошиљаоца, МТА са подршком за МТА-СТС полисе је тренутно неопходан, МТА-СТС није подржан изван кутије у МТА.
МТА-СТС користи листу поузданих основних ЦА.
МТА-СТС не штити од напада у којима нападач користи важећи сертификат. У већини случајева, МитМ у близини сервера подразумева могућност издавања сертификата. Такав напад се може открити помоћу транспарентности сертификата. Стога, генерално, МТА-СТС ублажава, али не у потпуности елиминише могућност пресретања саобраћаја.
Последње две тачке чине МТА-СТС мање сигурним од конкурентског ДАНЕ стандарда за СМТП (РФЦ 7672), али технички поузданијим, тј. за МТА-СТС постоји мала вероватноћа да писмо неће бити достављено због техничких проблема изазваних имплементацијом стандарда.
Конкурентски стандард - ДАНЕ
ДАНЕ користи ДНССЕЦ за објављивање информација о сертификатима и не захтева поверење у спољне ауторитете за сертификате, што је много безбедније. Али употреба ДНССЕЦ-а значајно чешће доводи до техничких кварова, на основу статистике током неколико година коришћења (иако генерално постоји позитиван тренд у поузданости ДНССЕЦ-а и његове техничке подршке). За имплементацију ДАНЕ-а у СМТП на страни примаоца, присуство ДНССЕЦ-а за ДНС зону је обавезно, а исправна подршка за НСЕЦ/НСЕЦ3 је неопходна за ДАНЕ, са којим постоје системски проблеми у ДНССЕЦ-у.
Ако ДНССЕЦ није исправно конфигурисан, то може довести до неуспеха испоруке поште ако страна која шаље подржава ДАНЕ, чак и ако страна која прима ништа не зна о томе. Стога, упркос чињеници да је ДАНЕ старији и сигурнији стандард и да је већ подржан у неким серверским софтверима на страни пошиљаоца, у ствари његова пенетрација остаје безначајна, многе организације нису спремне да га имплементирају због потребе имплементације ДНССЕЦ-а, ово је значајно успорило имплементацију ДАНЕ-а свих оних година колико стандард постоји.
ДАНЕ и МТА-СТС нису у сукобу једни са другима и могу се користити заједно.
Шта је са подршком за МТА-СТС у Маил.ру Маил-у?
Маил.ру већ дуже време објављује МТА-СТС политику за све главне домене. Тренутно имплементирамо клијентски део стандарда. У време писања, политике се примењују у режиму без блокирања (ако је испорука блокирана политиком, писмо ће бити испоручено преко „резервног“ сервера без примене смерница), тада ће режим блокирања бити принуђен за мали део одлазног СМТП саобраћаја, постепено ће за 100% саобраћаја бити Подржана је примена политика.
Ко још подржава стандард?
До сада политике МТА-СТС објављују приближно 0.05% активних домена, али, ипак, већ штите велики обим маил саобраћаја, јер Стандард подржавају главни играчи - Гоогле, Цомцаст и делимично Веризон (АОЛ, Иахоо). Многе друге поштанске службе најавиле су да ће подршка стандарду бити имплементирана у блиској будућности.
Како ће ово утицати на мене?
Не осим ако ваш домен не објави МТА-СТС политику. Ако објавите политику, имејлови за кориснике вашег сервера е-поште биће боље заштићени од пресретања.
Како да применим МТА-СТС?
МТА-СТС подршка на страни примаоца
Довољно је објавити политику преко ХТТПС-а и записа у ДНС-у, конфигурисати важећи сертификат једног од поузданих ЦА (Хајде да шифрујемо је могуће) за СТАРТТЛС у МТА (СТАРТТЛС је подржан у свим модерним МТА), нема посебне подршке од стране МТА је обавезан.
Корак по корак, то изгледа овако:
- Конфигуришите СТАРТТЛС у МТА-у који користите (постфик, еким, сендмаил, Мицрософт Екцханге, итд.).
- Уверите се да користите важећи сертификат (издао га је поуздани ЦА, није истекао, предмет сертификата одговара МКС запису који испоручује пошту за ваш домен).
- Конфигуришите ТЛС-РПТ запис преко којег ће се достављати извештаји о примени смерница (према услугама које подржавају слање ТЛС извештаја). Пример уноса (за домен екампле.цом):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:tlsrpt@example.com»Овај унос упућује пошиљаоце поште да шаљу статистичке извештаје о коришћењу ТЛС-а у СМТП-у
tlsrpt@exmple.com.Пратите извештаје неколико дана да бисте били сигурни да нема грешака.
- Објавите МТА-СТС политику преко ХТТПС-а. Политика се објављује као текстуална датотека са ЦРЛФ терминаторима линија према локацији.
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), Моде поставља режим примене политике, тестирање — режим тестирања (политика се не примењује), примена — „борбени“ режим. Прво објавите смернице са режимом: тестирање, ако нема проблема са политиком у тест режиму, после неког времена можете да пређете на режим: примени.У мк-у је наведена листа свих сервера поште који могу да прихватају пошту за ваш домен (сваки сервер мора имати конфигурисан сертификат који одговара имену наведеном у мк-у). Мак_аге специфицира време кеширања политике (када се запамћена политика примени чак и ако нападач блокира њену испоруку или поквари ДНС записе током времена кеширања, можете сигнализирати потребу да поново затражите политику променом мта-стс ДНС-а запис).
- Објавите ТКСТ запис у ДНС-у:
_mta-sts.example.com. TXT “v=STS1; id=someid;”Произвољни идентификатор (на пример, временска ознака) се може користити у пољу ид када се политика промени, то омогућава пошиљаоцима да схвате да треба поново да затраже кеширану политику (ако се идентификатор разликује од кеширане); кеширан један).
МТА-СТС подршка на страни пошиљаоца
До сада је са њом лоше, јер... свеж стандард.
- Еким - нема уграђене подршке, постоји скрипта треће стране
- Постфик - нема уграђене подршке, постоји скрипта треће стране која је детаљно описана на Хабре
Као поговор о „обавезном ТЛС-у“
У последње време регулатори обраћају пажњу на безбедност е-поште (и то је добра ствар). На пример, ДМАРЦ је обавезан за све владине агенције у Сједињеним Државама и све је више потребан у финансијском сектору, са продором стандарда који достиже 90% у регулисаним областима. Сада неки регулатори захтевају имплементацију „обавезног ТЛС-а” са појединачним доменима, али механизам за обезбеђивање „обавезног ТЛС-а” није дефинисан и у пракси се ово подешавање често имплементира на начин који чак ни минимално не штити од стварних напада који су већ предвиђено у механизмима као што су ДАНЕ или МТА-СТС.
Ако регулатор захтева имплементацију „обавезног ТЛС-а” са засебним доменима, препоручујемо да се МТА-СТС или његов делимични аналог размотри као најпогоднији механизам, што елиминише потребу да се безбедно подешава за сваки домен посебно. Ако имате потешкоћа са имплементацијом клијентског дела МТА-СТС-а (све док протокол не добије широку подршку, највероватније хоће), можемо препоручити овај приступ:
- Објавите МТА-СТС политику и/или ДАНЕ записе (ДАНЕ има смисла само ако је ДНССЕЦ већ омогућен за ваш домен, а МТА-СТС у сваком случају), ово ће заштитити саобраћај у вашем правцу и елиминисати потребу да питате друге поштанске услуге да конфигуришете обавезни ТЛС за ваш домен ако услуга поште већ подржава МТА-СТС и/или ДАНЕ.
- За велике услуге е-поште имплементирајте „аналог“ МТА-СТС кроз одвојена подешавања транспорта за сваки домен, што ће поправити МКС који се користи за преношење поште и захтеваће обавезну верификацију ТЛС сертификата за њега. Ако домени већ објављују МТА-СТС политику, то се вероватно може учинити безболно. Само по себи, омогућавање обавезног ТЛС-а за домен без поправљања релеја и верификације сертификата за њега је неефикасно са безбедносне тачке гледишта и не додаје ништа постојећим СТАРТТЛС механизмима.
Извор: ввв.хабр.цом
