Lühidalt öeldes on MTA-STS viis e-kirjade täiendavaks kaitsmiseks pealtkuulamise (st man-in-the-middle rünnakute ehk MitM) eest, kui need edastatakse meiliserverite vahel. See lahendab osaliselt meiliprotokollide pärandarhitektuuriprobleemid ja seda kirjeldatakse suhteliselt hiljutises standardis RFC 8461. Mail.ru on RuNeti esimene suurem meiliteenus, mis seda standardit rakendab. Ja seda on täpsemalt kirjeldatud lõike all.

Millise probleemi MTA-STS lahendab?

Ajalooliselt edastasid e-posti protokollid (SMTP, POP3, IMAP) teavet selge tekstina, mis võimaldas seda pealt kuulata näiteks sidekanalile juurdepääsul.

Kuidas näeb välja kirja ühelt kasutajalt teisele edastamise mehhanism:

Ajalooliselt oli MitM-i rünnak võimalik kõigis kohtades, kus kiri liigub.

RFC 8314 nõuab TLS-i kasutamist meilikasutaja rakenduse (MUA) ja meiliserveri vahel. Kui teie server ja kasutatavad meilirakendused ühilduvad standardiga RFC 8314, siis olete (suures osas) välistanud võimaluse Man-in-the-Middle rünnakuteks kasutaja ja meiliserverite vahel.

Üldtunnustatud tavade (standardiseeritud RFC 8314 järgi) järgimine välistab rünnaku kasutaja lähedal:

Mail.ru meiliserverid vastasid standardile RFC 8314 juba enne standardi vastuvõtmist; tegelikult salvestab see lihtsalt juba aktsepteeritud tavad ja me ei pidanud midagi täiendavat seadistama. Kuid kui teie meiliserver lubab kasutajatel siiski kasutada ebaturvalisi protokolle, rakendage kindlasti selle standardi soovitusi, sest Tõenäoliselt töötavad vähemalt mõned teie kasutajad meiliga ilma krüptimiseta, isegi kui te seda toetate.

Meiliklient töötab alati sama organisatsiooni sama meiliserveriga. Ja saate sundida kõiki kasutajaid turvalisel viisil ühendama ja seejärel mitteturvalistele kasutajatele ühenduse loomise tehniliselt võimatuks teha (see on täpselt see, mida RFC 8314 nõuab). See on mõnikord raske, kuid teostatav. Liiklus meiliserverite vahel on endiselt keerulisem. Serverid kuuluvad erinevatesse organisatsioonidesse ja neid kasutatakse sageli "seadista ja unusta" režiimis, mis muudab võimatuks lülituda korraga turvalisele protokollile ilma ühendust rikkumata. SMTP on pikka aega pakkunud STARTTLS-i laiendust, mis võimaldab krüptimist toetavatel serveritel TLS-ile lülituda. Kuid ründaja, kellel on võimalus liiklust mõjutada, võib selle käsu toe kohta teabe "välja lõigata" ja sundida servereid suhtlema lihtteksti protokolli (nn alandamise rünnak) abil. Samal põhjusel ei kontrolli STARTTLS tavaliselt sertifikaadi kehtivust (ebausaldusväärne sertifikaat võib kaitsta passiivsete rünnete eest ja see pole halvem, kui sõnumi saatmine selge tekstina). Seetõttu kaitseb STARTTLS ainult passiivse pealtkuulamise eest.

MTA-STS kõrvaldab osaliselt kirjade pealtkuulamise probleemi meiliserverite vahel, kui ründajal on võimalus liiklust aktiivselt mõjutada. Kui saaja domeen avaldab MTA-STS-i poliitika ja saatja server toetab MTA-STS-i, saadab see meili ainult TLS-ühenduse kaudu, ainult poliitikaga määratletud serveritesse ja ainult serveri sertifikaadi kontrollimisega.

Miks osaliselt? MTA-STS töötab ainult siis, kui mõlemad pooled on selle standardi rakendamise eest hoolt kandnud, ja MTA-STS ei kaitse stsenaariumide eest, mille korral ründaja suudab hankida kehtiva domeenisertifikaadi ühelt avalikult CA-lt.

Kuidas MTA-STS töötab

saaja

Seadistab STARTTLS-i toe meiliserveris kehtiva sertifikaadiga.
Avaldab MTA-STS poliitika HTTPS-i kaudu, avaldamiseks kasutatakse näiteks spetsiaalset mta-sts domeeni ja spetsiaalset tuntud teed https://mta-sts.mail.ru/.well-known/mta-sts.txt. Reegel sisaldab loendit meiliserveritest (mx), millel on õigus selle domeeni jaoks meile vastu võtta.
Avaldab DNS-is poliitikaversiooniga spetsiaalse TXT-kirje _mta-sts. Kui poliitika muutub, tuleb seda kirjet värskendada (see annab saatjale märku poliitika uuesti päringu esitamisest). Näiteks, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Saatja

Saatja taotleb _mta-sts DNS-kirjet ja kui see on saadaval, teeb poliitikapäringu HTTPS-i kaudu (kontrollib sertifikaati). Saadud poliitika salvestatakse vahemällu (juhuks, kui ründaja blokeerib sellele juurdepääsu või võltsib DNS-kirjet).

Kirja saatmisel kontrollitakse, et:

server, kuhu kiri toimetatakse, on poliitikas;
server aktsepteerib kirju TLS-i (STARTTLS) abil ja sellel on kehtiv sertifikaat.

MTA-STS eelised

MTA-STS kasutab tehnoloogiaid, mis on enamikus organisatsioonides juba juurutatud (SMTP+STARTTLS, HTTPS, DNS). Vastuvõtja poolel rakendamiseks pole standardile spetsiaalset tarkvaratuge vaja.

MTA-STS miinused

Vajalik on jälgida veebi- ja meiliserveri sertifikaadi kehtivust, nimede vastavust ja õigeaegset uuendamist. Sertifikaadiga seotud probleemid põhjustavad selle, et posti ei saa kohale toimetada.

Saatja poolel on nõutav MTA-STS-i toega MTA, praegu ei toetata MTA-STS-i MTA-s.

MTA-STS kasutab usaldusväärsete juur-CA-de loendit.

MTA-STS ei kaitse rünnete eest, mille puhul ründaja kasutab kehtivat sertifikaati. Enamikul juhtudel tähendab serveri lähedal asuv MitM sertifikaadi väljastamise võimalust. Sellise rünnaku saab tuvastada Certificate Transparency abil. Seetõttu üldiselt leevendab MTA-STS liikluse pealtkuulamise võimalust, kuid ei välista seda täielikult.

Viimased kaks punkti muudavad MTA-STS SMTP jaoks konkureerivast DANE standardist (RFC 7672) vähem turvaliseks, kuid tehniliselt töökindlamaks, s.t. MTA-STS puhul on väike tõenäosus, et kiri jääb standardi rakendamisest tingitud tehniliste probleemide tõttu kättetoimetamata.

Võistlusstandard - DANE

DANE kasutab sertifikaaditeabe avaldamiseks DNSSEC-i ega vaja usaldust väliste sertifitseerimisasutuste vastu, mis on palju turvalisem. Kuid DNSSEC-i kasutamine põhjustab mitmeaastase kasutuse statistika põhjal oluliselt sagedamini tehnilisi tõrkeid (kuigi DNSSEC-i ja selle tehnilise toe usaldusväärsuses on üldiselt positiivne trend). DANE juurutamiseks SMTP-s adressaadi poolel on DNSSEC-i olemasolu DNS-tsooni jaoks kohustuslik ja DANE jaoks on oluline NSEC/NSEC3 korrektne tugi, millega DNSSEC-is on süsteemseid probleeme.

Kui DNSSEC pole õigesti konfigureeritud, võib see põhjustada kirjade edastamise tõrkeid, kui saatja pool toetab DANE-i, isegi kui vastuvõttev pool ei tea sellest midagi. Seetõttu, hoolimata asjaolust, et DANE on vanem ja turvalisem standard ning seda toetatakse juba mõnes saatja poole serveritarkvaras, jääb selle levik tegelikult ebaoluliseks, paljud organisatsioonid ei ole DNSSECi juurutamise vajaduse tõttu valmis seda juurutama, see on oluliselt aeglustanud DANE rakendamist kõik need aastad, mil standard on eksisteerinud.

DANE ja MTA-STS ei ole omavahel vastuolus ja neid saab kasutada koos.

Mis on Mail.ru Maili MTA-STS-i toega?

Mail.ru on juba mõnda aega avaldanud MTA-STS poliitikat kõigi suuremate domeenide jaoks. Hetkel juurutame standardi kliendiosa. Artikli kirjutamise ajal rakendatakse poliitikaid mitteblokeerivas režiimis (kui kättetoimetamine on poliitikaga blokeeritud, toimetatakse kiri läbi varuserveri ilma poliitikaid rakendamata), siis on blokeerimisrežiim väikese osa jaoks sunnitud väljaminevast SMTP-liiklusest järk-järgult 100% liiklusest. Toetatakse poliitikate jõustamist.

Kes veel standardit toetab?

Seni avaldavad MTA-STS-i poliitikad ligikaudu 0.05% aktiivsetest domeenidest, kuid sellegipoolest kaitsevad need juba suurt hulka meililiiklust, sest Standardit toetavad suuremad tegijad – Google, Comcast ja osaliselt Verizon (AOL, Yahoo). Paljud teised postiteenused on teatanud, et lähiajal hakatakse standardit toetama.

Kuidas see mind mõjutab?

Mitte välja arvatud juhul, kui teie domeen avaldab MTA-STS poliitikat. Kui avaldate reeglid, on teie meiliserveri kasutajatele mõeldud meilid pealtkuulamise eest paremini kaitstud.

Kuidas MTA-STS-i rakendada?

MTA-STS tugi saaja poolel

Piisab poliitika avaldamisest HTTPS-i ja DNS-i kirjete kaudu, mõne usaldusväärse CA-de kehtiva sertifikaadi konfigureerimisest (võimalik krüpteerida) STARTTLS-i jaoks MTA-s (STARTTLS-i toetavad kõik kaasaegsed MTA-d), erituge pole MTA on vajalik.

Samm-sammult näeb see välja selline:

Seadistage STARTTLS kasutatavas MTA-s (postfix, exim, sendmail, Microsoft Exchange jne).
Veenduge, et kasutate kehtivat sertifikaati (väljastanud usaldusväärne CA, mitte aegunud, sertifikaadi teema ühtib MX-kirjega, mis edastab teie domeeni kirju).
Konfigureerige TLS-RPT kirje, mille kaudu toimetatakse poliitikarakenduse aruanded (TLS-i aruannete saatmist toetavate teenuste kaudu). Näidiskirje (domeeni example.com jaoks):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
See kirje annab meili saatjatele ülesandeks saata statistilised aruanded TLS-i kasutamise kohta SMTP-s aadressile [email protected].

Jälgige aruandeid mitu päeva, et veenduda, et vigu pole.
Avaldage MTA-STS poliitika HTTPS-i kaudu. Poliitika avaldatakse tekstifailina, millel on asukoha järgi CRLF-i realõpetajad.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Näidispoliitika:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Versiooniväli sisaldab poliitika versiooni (praegu STSv1), Mode määrab poliitika rakendusrežiimi, testimine — testrežiim (poliitikat ei rakendata), jõustamine — võitlusrežiim. Esmalt avaldage poliitika režiimiga: testimine, kui testrežiimis poliitikaga probleeme pole, saate mõne aja pärast lülituda režiimi: jõustada.

Mx-s on määratud loend kõigist meiliserveritest, mis võivad teie domeeni jaoks kirju vastu võtta (igal serveril peab olema konfigureeritud sertifikaat, mis ühtib mx-s määratud nimega). Max_age määrab poliitika vahemällu salvestamise aja (kui meeldejäetud poliitikat rakendatakse isegi siis, kui ründaja blokeerib selle edastamise või rikub DNS-kirjeid vahemällu salvestamise ajal, saate poliitika uuesti taotlemise vajadusest märku anda mta-sts DNS-i muutmisega rekord).
TXT-kirje avaldamine DNS-is:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
ID väljal võib kasutada suvalist identifikaatorit (näiteks ajatemplit); kui poliitika muutub, peaks see muutuma, see võimaldab saatjatel mõista, et nad peavad vahemällu salvestatud poliitikat uuesti taotlema (kui identifikaator erineb vahemällu salvestatud).

MTA-STS tugi saatja poolel

Siiani on temaga halb, sest... värske standard.

Exim – sisseehitatud tuge pole, olemas on kolmanda osapoole skript https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - sisseehitatud tugi puudub, on olemas kolmanda osapoole skript, mida kirjeldatakse üksikasjalikult Habré's https://habr.com/en/post/424961/

Järelsõnana "kohustuslikust TLS-ist"

Viimasel ajal on reguleerivad asutused pööranud tähelepanu e-posti turvalisusele (ja see on hea). Näiteks DMARC on kohustuslik kõikidele USA valitsusasutustele ja seda nõutakse üha enam finantssektoris, kusjuures standardi levik ulatub reguleeritud valdkondades 90%-ni. Nüüd nõuavad mõned regulaatorid "kohustusliku TLS-i" rakendamist üksikute domeenide puhul, kuid "kohustusliku TLS-i" tagamise mehhanism pole määratletud ja praktikas rakendatakse seda seadistust sageli viisil, mis ei kaitse isegi minimaalselt reaalsete rünnete eest, mis juba on ette nähtud sellistes mehhanismides nagu DANE või MTA-STS.

Kui regulaator nõuab eraldi domeenidega “kohustusliku TLS-i” juurutamist, soovitame sobivaimaks mehhanismiks pidada MTA-STS-i või selle osalist analoogi, see välistab vajaduse teha iga domeeni jaoks eraldi turvalisi seadistusi. Kui teil on raskusi MTA-STS-i kliendiosa rakendamisega (kuni protokoll ei ole saanud laialdast toetust, siis tõenäoliselt saavad nad seda teha), võime soovitada järgmist lähenemist:

Avaldage MTA-STS poliitika ja/või DANE kirjed (DANE on mõttekas ainult siis, kui DNSSEC on teie domeeni jaoks juba lubatud ja MTA-STS igal juhul), see kaitseb teie suunal liiklust ja välistab vajaduse küsida teisi meiliteenuseid oma domeeni jaoks kohustusliku TLS-i konfigureerimiseks, kui meiliteenus juba toetab MTA-STS-i ja/või DANE-i.
Suurte meiliteenuste puhul rakendage iga domeeni jaoks eraldi transpordiseadete kaudu MTA-STS-i "analoog", mis parandab kirjade edastamiseks kasutatava MX-i ja nõuab selle jaoks TLS-i sertifikaadi kohustuslikku kontrollimist. Kui domeenid juba avaldavad MTA-STS poliitika, saab seda tõenäoliselt valutult teha. Iseenesest on domeenile kohustusliku TLS-i lubamine ilma releed parandamata ja selle sertifikaati kontrollimata turvalisuse seisukohalt ebaefektiivne ega lisa midagi olemasolevatele STARTTLS-i mehhanismidele.

Allikas: www.habr.com

Mail.ru hakkab testirežiimis rakendama MTA-STS poliitikaid