Калі коратка, то 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. Але атакавалы, у якога ёсць магчыма ўплываць на трафік, можа «выразаць» інфармацыю аб падтрымцы гэтай каманды і прымусіць серверы мець зносіны па звычайным тэкставым пратаколе (т.зв. downgrade attack – атака на паніжэнне версіі пратакола). Па гэтай жа прычыне, для 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-зоны абавязкова, прычым для DANE істотная карэктная падтрымка 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:[email protected]»Гэты запіс інструктуе адпраўнікаў пошты слаць статыстычныя справаздачы па выкарыстанні TLS у SMTP на адрас
[email protected].Сачыце за справаздачам некалькі дзён, пераканайцеся ў адсутнасці памылак.
- Апублікуйце палітыку 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 - няма убудаванай падтрымкі, ёсць іншы скрыпт
- Postfix – няма ўбудаванай падтрымкі, ёсць іншы скрыпт пра які падрабязна расказана на Хабре
У якасці пасляслоўя аб "mandatory TLS"
У апошні час рэгулятары зважаюць на бяспеку пошты (і гэта добра). Напрыклад, DMARC абавязковы для ўсіх дзяржустаноў у ЗША і ўсё часцей патрабуецца ў фінансавай сферы, у рэгуляваных сферах пранікненне стандарту дасягае 90%. Цяпер некаторыя рэгулятары патрабуюць укараненні "mandatory TLS" з асобнымі даменамі, але пры гэтым механізм забеспячэння "mandatory TLS" не вызначаецца і на практыцы гэтая настройка часта ўкараняецца такім спосабам, які нават мінімальна не абараняе ад рэальных нападаў, якія ўжо прадугледжаны ў такіх механізмах як DANE ці MTA-STS.
Калі рэгулятар патрабуе рэалізацыі "mandatory TLS" з асобнымі даменамі, мы рэкамендуем разгледзець MTA-STS або яго частковы аналог як найболей падыходны механізм, ён ухіляе неабходнасць рабіць бяспечныя налады для кожнага дамена ў асобнасці. Калі ў вас ёсць складанасці з рэалізацыяй кліенцкай часткі MTA-STS (пакуль пратакол не атрымаў шырокай падтрымкі яны хутчэй за ўсё будуць), можна рэкамендаваць такі падыход:
- Апублікуйце палітыку MTA-STS і/або запісы DANE (DANE мае сэнс дадаваць толькі калі для вашага дамена ўжо ўключаны DNSSEC, а MTA-STS у любым выпадку), гэта абароніць трафік у ваш бок і пазбавіць ад неабходнасці прасіць іншыя паштовыя службы наладзіць mandatory TLS для вашага дамена, калі паштовая служба ўжо падтрымлівае MTA-STS і/ці DANE.
- Для буйных паштовых сэрвісаў рэалізуйце "аналаг" MTA-STS праз асобныя наладкі транспарту для кожнага дамена, якія зафіксуюць MX выкарыстоўваецца для рэлеінгу пошты і будуць патрабаваць для яго абавязковай праверкі TLS-сертыфіката. Калі дамены ўжо публікуюць палітыку MTA-STS, гэта, хутчэй за ўсё, можна зрабіць бязбольна. Само па сабе ўключэнне абавязковага TLS для дамена без фіксацыі рэлея і праверкі сертыфіката для яго неэфектыўна з пункта гледжання бяспекі і нічога не дадае да наяўных механізмаў STARTTLS.
Крыніца: habr.com