Í stuttu máli, MTA-STS er leið til að vernda tölvupóst enn frekar fyrir hlerun (þ.e. árásir á milli manna aka MitM) þegar hann er sendur á milli póstþjóna. Það leysir að hluta til eldri byggingarvandamál tölvupóstsamskiptareglur og er lýst í tiltölulega nýlegum staðli RFC 8461. Mail.ru er fyrsta stóra póstþjónustan á RuNet til að innleiða þennan staðal. Og það er nánar lýst undir niðurskurðinum.

Hvaða vandamál leysir MTA-STS?

Sögulega sendu tölvupóstsamskiptareglur (SMTP, POP3, IMAP) upplýsingar í skýrum texta, sem gerði það mögulegt að stöðva þær, til dæmis þegar aðgangur var að samskiptarás.

Hvernig lítur aðferðin við að koma bréfi frá einum notanda til annars út:

Sögulega séð var MitM árás möguleg á öllum stöðum þar sem póstur er í umferð.

RFC 8314 krefst notkunar á TLS á milli póstnotendaforritsins (MUA) og póstþjónsins. Ef þjónninn þinn og póstforritin sem þú notar eru í samræmi við RFC 8314, þá hefur þú (að mestu leyti) eytt möguleikanum á Man-in-the-Middle árásum milli notandans og póstþjónanna.

Eftir almennt viðurkenndar venjur (staðlaðar af RFC 8314) koma í veg fyrir árásina nálægt notandanum:

Mail.ru póstþjónar uppfylltu RFC 8314 jafnvel áður en staðallinn var tekinn upp; í raun fangar hann einfaldlega viðteknar venjur og við þurftum ekki að stilla neitt til viðbótar. En ef póstþjónninn þinn leyfir notendum að nota óöruggar samskiptareglur, vertu viss um að innleiða ráðleggingar þessa staðals, vegna þess að Líklegast vinna að minnsta kosti sumir notenda þinna með póst án dulkóðunar, jafnvel þótt þú styður það.

Póstforritið vinnur alltaf með sama póstþjóni sömu fyrirtækis. Og þú getur þvingað alla notendur til að tengjast á öruggan hátt og síðan gert það tæknilega ómögulegt fyrir óörugga notendur að tengjast (þetta er nákvæmlega það sem RFC 8314 krefst). Þetta er stundum erfitt, en gerlegt. Umferð á milli póstþjóna er enn flóknari. Netþjónar tilheyra mismunandi stofnunum og eru oft notaðir í „stillingu og gleymdu“ ham, sem gerir það ómögulegt að skipta yfir í örugga samskiptareglu í einu án þess að rjúfa tenginguna. SMTP hefur lengi útvegað STARTTLS viðbótina, sem gerir netþjónum sem styðja dulkóðun að skipta yfir í TLS. En árásarmaður sem hefur getu til að hafa áhrif á umferð getur „klippt út“ upplýsingar um stuðning við þessa skipun og þvingað netþjónana til að eiga samskipti með því að nota venjuleg textasamskiptareglur (svokölluð niðurfærsluárás). Af sömu ástæðu athugar STARTTLS yfirleitt ekki gildi vottorðsins (ótraust vottorð getur verndað gegn óbeinum árásum og það er ekkert verra en að senda skilaboð í skýrum texta). Þess vegna verndar STARTTLS aðeins gegn óvirku hlerun.

MTA-STS útilokar að hluta vandamálið við að stöðva bréf á milli póstþjóna, þegar árásarmaðurinn hefur getu til að hafa virkan áhrif á umferð. Ef lén viðtakandans birtir MTA-STS stefnu og miðlari sendanda styður MTA-STS, mun það aðeins senda tölvupóstinn í gegnum TLS tengingu, aðeins til netþjóna sem skilgreindir eru af stefnunni, og aðeins með staðfestingu á vottorði miðlarans.

Hvers vegna að hluta? MTA-STS virkar aðeins ef báðir aðilar hafa gætt þess að innleiða þennan staðal og MTA-STS verndar ekki gegn atburðarás þar sem árásarmaður getur fengið gilt lénsvottorð frá einu af opinberu CAs.

Hvernig MTA-STS virkar

viðtakandi

Stillir STARTTLS stuðning með gildu vottorði á póstþjóninum.
Birtir MTA-STS stefnuna í gegnum HTTPS; sérstakt mta-sts lén og sérstakt vel þekkt leið eru notuð til birtingar, td. https://mta-sts.mail.ru/.well-known/mta-sts.txt. Stefnan inniheldur lista yfir póstþjóna (mx) sem hafa rétt til að taka á móti pósti fyrir þetta lén.
Birtir sérstaka TXT skrá _mta-sts í DNS með stefnu útgáfunni. Þegar stefnan breytist verður að uppfæra þessa færslu (þetta gefur sendanda merki um að spyrja aftur um stefnuna). Til dæmis, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Sendandi

Sendandi biður um _mta-sts DNS skrána og ef hún er tiltæk gerir hann stefnubeiðni í gegnum HTTPS (athugar vottorðið). Stefnan sem myndast er í skyndiminni (ef árásarmaður lokar fyrir aðgang að henni eða spillir DNS-skránni).

Þegar þú sendir póst er hakað við að:

þjónninn sem póstur er sendur á er í stefnunni;
þjónninn tekur við pósti með TLS (STARTTLS) og hefur gilt vottorð.

Kostir MTA-STS

MTA-STS notar tækni sem þegar er innleidd í flestum stofnunum (SMTP+STARTTLS, HTTPS, DNS). Til innleiðingar á viðtakandahliðinni þarf ekki sérstakan hugbúnaðarstuðning fyrir staðalinn.

Ókostir MTA-STS

Nauðsynlegt er að fylgjast með gildi vef- og póstþjónsvottorðs, samsvörun nafna og tímanlega endurnýjun. Vandamál með skírteinið munu leiða til þess að póstur verður ekki afhentur.

Á sendandahliðinni er krafist MTA með stuðningi við MTA-STS stefnur; eins og er er MTA-STS ekki stutt beint úr kassanum í MTA.

MTA-STS notar lista yfir trausta rótarstjóra.

MTA-STS verndar ekki gegn árásum þar sem árásarmaðurinn notar gilt vottorð. Í flestum tilfellum gefur MitM nálægt þjóninum í skyn að hægt sé að gefa út vottorð. Slíka árás er hægt að greina með því að nota Certificate Transparency. Þess vegna dregur MTA-STS almennt úr, en útilokar ekki að fullu, möguleikanum á umferðahlerun.

Síðustu tveir punktarnir gera MTA-STS óöruggari en samkeppnisstaða DANE fyrir SMTP (RFC 7672), en tæknilega áreiðanlegri, þ.e. fyrir MTA-STS eru litlar líkur á að bréfið verði ekki afhent vegna tæknilegra vandamála sem stafa af innleiðingu staðalsins.

Keppnisstaðall - DANKI

DANE notar DNSSEC til að birta upplýsingar um vottorð og krefst ekki trausts á ytri vottorðayfirvöldum, sem er miklu öruggara. En notkun DNSSEC leiðir marktækt oftar til tæknilegra bilana, byggt á tölfræði yfir nokkurra ára notkun (þótt almennt sé jákvæð þróun í áreiðanleika DNSSEC og tæknilega aðstoð þess). Til að innleiða DANE í SMTP á viðtakandahliðinni er tilvist DNSSEC fyrir DNS svæðið skylda og réttur stuðningur við NSEC/NSEC3 er nauðsynlegur fyrir DANE, sem eru kerfisbundin vandamál með í DNSSEC.

Ef DNSSEC er ekki rétt stillt getur það leitt til bilunar í póstsendingu ef sendandi hlið styður DANE, jafnvel þó að móttökuaðili viti ekkert um það. Þess vegna, þrátt fyrir þá staðreynd að DANE er eldri og öruggari staðall og er nú þegar studdur í sumum netþjónahugbúnaði á sendandahlið, er skarpskyggni hans enn óveruleg, margar stofnanir eru ekki tilbúnar til að innleiða hann vegna þess að þörf er á að innleiða DNSSEC, þetta hefur dregið verulega úr innleiðingu DANE öll þau ár sem staðallinn hefur verið til.

DANE og MTA-STS stangast ekki á við hvort annað og hægt er að nota þau saman.

Hvað er með MTA-STS stuðning í Mail.ru Mail?

Mail.ru hefur verið að birta MTA-STS stefnu fyrir öll helstu lén í nokkurn tíma. Við erum núna að innleiða viðskiptavinahluta staðalsins. Þegar þetta er skrifað er reglum beitt í ólokandi ham (ef afhending er lokuð af stefnu verður bréfið afhent í gegnum „vara“ netþjón án þess að beita reglum), þá verður lokunarhamur þvingaður að litlu leyti af útleiðinni SMTP umferð, smám saman fyrir 100% af umferð mun það vera Framfylgni stefnu er studd.

Hverjir aðrir styðja staðalinn?

Hingað til hafa MTA-STS reglur birt um það bil 0.05% virkra léna, en engu að síður vernda þær nú þegar mikið magn af póstumferð, vegna þess að Staðallinn er studdur af helstu aðilum - Google, Comcast og að hluta til Verizon (AOL, Yahoo). Margar aðrar póstþjónustur hafa tilkynnt að stuðningur við staðalinn verði innleiddur á næstunni.

Hvaða áhrif mun þetta hafa á mig?

Ekki nema lénið þitt birti MTA-STS stefnu. Ef þú birtir stefnuna verður tölvupóstur fyrir notendur póstþjónsins betur varinn fyrir hlerun.

Hvernig innleiða ég MTA-STS?

MTA-STS stuðningur á viðtakanda hlið

Það er nóg að birta stefnuna í gegnum HTTPS og skrár í DNS, stilla gilt vottorð frá einu af traustu CA (Við skulum dulkóða er mögulegt) fyrir STARTTLS í MTA (STARTTLS er stutt í öllum nútíma MTA), enginn sérstakur stuðningur frá MTA er krafist.

Skref fyrir skref lítur þetta svona út:

Stilltu STARTTLS í MTA sem þú ert að nota (postfix, exim, sendmail, Microsoft Exchange osfrv.).
Gakktu úr skugga um að þú sért að nota gilt vottorð (útgefið af traustum CA, ekki útrunnið, efni vottorðsins passar við MX-skrána sem sendir póst fyrir lénið þitt).
Stilltu TLS-RPT færslu þar sem skýrslur um stefnu umsóknar verða afhentar (af þjónustu sem styður sendingu TLS skýrslna). Dæmi um færslu (fyrir example.com lénið):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Þessi færsla gefur póstsenendum fyrirmæli um að senda tölfræðilegar skýrslur um TLS notkun í SMTP til [email protected].

Fylgstu með skýrslunum í nokkra daga til að ganga úr skugga um að engar villur séu.
Birtu MTA-STS stefnuna yfir HTTPS. Stefnan er birt sem textaskrá með CRLF línulokum eftir staðsetningu.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Dæmi um stefnu:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Útgáfureiturinn inniheldur útgáfu stefnunnar (sem stendur STSv1), Mode stillir stefnu umsóknarham, prófun — prófunarhamur (reglunni er ekki beitt), framfylgja — „bardaga“ ham. Birtu fyrst stefnuna með ham: prófun, ef engin vandamál eru með stefnuna í prófunarham, eftir smá stund geturðu skipt yfir í ham: framfylgja.

Í mx er tilgreindur listi yfir alla póstþjóna sem geta tekið við pósti fyrir lénið þitt (hver miðlari verður að hafa skilríki stillt sem passar við nafnið sem tilgreint er í mx). Max_age tilgreinir skyndiminnistíma reglunnar (þegar reglunni sem er minnst verður beitt, jafnvel þó að árásarmaðurinn loki á afhendingu hennar eða skemmi DNS-skrárnar á meðan á skyndiminni stendur, geturðu gefið til kynna að þú þurfir að biðja um regluna aftur með því að breyta mta-sts DNS met).
Birta TXT færslu í DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Hægt er að nota handahófskennt auðkenni (til dæmis tímastimpil) í auðkennisreitnum; þegar stefnan breytist ætti hún að breytast, þetta gerir sendendum kleift að skilja að þeir þurfa að biðja um skyndiminni stefnuna aftur (ef auðkennið er annað en einn í skyndiminni).

MTA-STS stuðningur á sendandahlið

Hingað til hefur það gengið illa með hana, því... ferskur staðall.

Exim - enginn innbyggður stuðningur, það er þriðja aðila handrit https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - það er enginn innbyggður stuðningur, það er þriðja aðila handrit sem er lýst í smáatriðum á Habré https://habr.com/en/post/424961/

Sem eftirmál um „skyldubundið TLS“

Undanfarið hafa eftirlitsaðilar verið að fylgjast með tölvupóstöryggi (og það er gott). Til dæmis er DMARC skylda fyrir allar opinberar stofnanir í Bandaríkjunum og er í auknum mæli krafist í fjármálageiranum, með útbreiðslu staðalsins nær 90% á eftirlitssvæðum. Nú þurfa sumir eftirlitsaðilar að innleiða „skyldubundið TLS“ með einstökum lénum, en vélbúnaðurinn til að tryggja „skyldubundinn TLS“ er ekki skilgreindur og í reynd er þessi stilling oft útfærð á þann hátt sem verndar ekki einu sinni í lágmarki gegn raunverulegum árásum sem eru nú þegar kveðið á um í kerfi eins og DANE eða MTA-STS.

Ef eftirlitsaðilinn krefst innleiðingar á „skyldubundnu TLS“ með aðskildum lénum, mælum við með að líta á MTA-STS eða hliðstæðu þess að hluta sem heppilegasta fyrirkomulagið, það útilokar þörfina á að gera öruggar stillingar fyrir hvert lén fyrir sig. Ef þú átt í erfiðleikum með að innleiða viðskiptavinahluta MTA-STS (þar til samskiptareglan hefur fengið víðtækan stuðning, munu þeir líklegast gera það), getum við mælt með þessari aðferð:

Birtu MTA-STS stefnu og/eða DANE færslur (DANE er aðeins skynsamlegt ef DNSSEC er nú þegar virkt fyrir lénið þitt, og MTA-STS í öllum tilvikum), þetta mun vernda umferð í þína átt og útiloka þörfina á að spyrja aðra póstþjónustu til að stilla skyldubundið TLS fyrir lénið þitt ef póstþjónustan styður nú þegar MTA-STS og/eða DANE.
Fyrir stórar tölvupóstþjónustur skaltu innleiða „hliðstæðu“ af MTA-STS í gegnum aðskildar flutningsstillingar fyrir hvert lén, sem mun laga MX sem notað er fyrir póstmiðlun og mun krefjast skyldubundinnar staðfestingar á TLS vottorði fyrir það. Ef lénin birta nú þegar MTA-STS stefnu er líklega hægt að gera þetta sársaukalaust. Út af fyrir sig er það óvirkt frá öryggissjónarmiði að virkja skyldubundið TLS fyrir lén án þess að laga gengið og staðfesta vottorðið fyrir það og bætir engu við núverandi STARTTLS kerfi.

Heimild: www.habr.com

Mail.ru póstur byrjar að beita MTA-STS stefnum í prófunarham