Kokkuvõttes on MTA-STS viis kaitsta kirju häkkerite keskel toimuvate rünnakute (ehk MitM) eest, kui need edastatakse postiserverite vahel. See lahendab osaliselt e-posti protokollide ajaloolisi arhitektuurilisi probleeme ja on kirjeldatud suhteliselt värskes standardis RFC 8461. Mail.ru on esimene suur e-posti teenus Runitis, mis on rakendanud seda standardit. Üksikasjalikumalt räägitakse juba allpool.

Millise probleemi lahendab MTA-STS?

Ajalooliselt edastasid e-posti protokollid (SMTP, POP3, IMAP) teavet avatud kujul, mis võimaldas selle pealtkuulamist, näiteks juurdepääsul sidekanalile.

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

Ajalooliselt oli MitM rünnak võimalik igas kohas, kus post liigub.

Standard RFC 8314 nõuab TLS-i kohustuslikku kasutamist kasutaja postirakenduse (MUA) ja postiserveri vahel. Kui teie server ja kasutatavad postirakendused vastavad RFC 8314-le, siis olete (suurel määral) kõrvaldanud Man-in-the-Middle rünnakud kasutaja ja postiserverite vahel.

Kasutatavate tavade järgimine (standardiseeritud RFC 8314) kõrvaldab rünnaku kasutaja läheduses:

Mail.ru postiserverid vastasid RFC 8314 nõuetele juba enne standardi vastuvõtmist, tegelikult fikseerib see lihtsalt juba kehtestatud praktikad ja me ei pidanud midagi lisaks seadistama. Kuid kui teie postiserver lubab endiselt kasutajatel kasutada ebaturvalisi protokolle, rakendage kindlasti selle standardi soovitusi, kuna tõenäoliselt töötavad vähemalt osa teie kasutajatest postiga ilma krüpteerimiseta, isegi kui te seda toetate.

Postikliendi töötab alati ühe ja sama posti serveriga, mis kuulub sama organisatsiooni. Samuti on võimalik sundida kõiki kasutajaid ühenduma turvaliselt, muutes samas ebaturvalise ühenduse tehniliselt võimatuks (just seda nõuab RFC 8314). See on mõnikord keeruline, kuid teostatav. Postiserverite vahel on liiklus veel keerulisem. Serverid kuuluvad erinevatele organisatsioonidele ja neid kasutatakse sageli režiimis „paned ja unustad“, mis muudab turvalisse protokolli ülemineku korraga võimatuks, ilma et ühendus katkeks. SMTP-s on juba pikka aega olemas laiendus STARTTLS, mis võimaldab krüpteerimist toetavatel serveritel TLS-ile üle minna. Kuid ründajal, kellel on võimalus liiklust muuta, võib olla võimalik „ära lõigata“ teave selle käsu toetamise kohta ja sundida servereid suhtlema tavalises tekstiprotokollis (nn downgrade attack — protokolli versiooni alandamise rünnak). Sama põhjusel ei kontrollita STARTTLS-i puhul tavaliselt sertifikaadi vastavust (usaldusväärne sertifikaat võib kaitsta passiivsete rünnakute eest ja see pole halvem kui kirja saatmine avatud tekstina). Seetõttu kaitseb STARTTLS ainult passiivse kuulamise eest.

MTA-STS lahendab osaliselt probleemi postide ülevõtmisega postiserverite vahel, kui ründajal on võimalus aktiivselt liiklust mõjutada. Kui saaja domeen avaldab MTA-STS poliitika ja saatja server toetab MTA-STS, saadetakse kiri ainult TLS-ühenduse kaudu, ainult poliitikas määratletud serveritele ja ainult serveri sertifikaadi kontrollimisega.

Miks osaliselt? MTA-STS töötab ainult juhul, kui mõlemad osalised on hoolitsenud selle standardi rakendamise eest, ning MTA-STS ei kaitse stsenaariumite eest, kus ründajal on võimalus saada kehtiv domeeni sertifikaat mõnest avalikust CA-st.

Kuidas MTA-STS töötab

Saaja

1. Seab POSTI serveris üles STARTTLS toe kehtiva sertifikaadiga. 
2. Avaldab poliitikat MTA-STS kaudu HTTPS-i, kasutades avaldamiseks spetsiaalset domeeni mta-sts ja erilist well-known teed, näiteks https://mta-sts.mail.ru/.well-known/mta-sts.txt. Poliitika sisaldab loetelu posti serveritest (mx), kellel on õigus saada postitusi selle domeeni jaoks.
3. Avaldab erilise TXT-kirje _mta-sts DNS-is poliitika versiooniga. Poliitika muutumisel tuleb seda kirjet uuendada (see annab saatjale märku poliitika uuesti taotlemisest). Näiteks _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Saatja

Saatja küsib DNS-kirjet _mta-sts, kui see on olemas, teeb ta poliitika taotluse HTTPS-i kaudu (kontrollides sertifikaati). Saadud poliitika vahetatakse mällu (juhuks, kui ründaja blokeerib sellele juurdepääsu või asendab DNS-kirje).

Kliendi postitamisel kontrollitakse, et:

• postikserver, kuhu kiri toimetatakse, on poliitikas;
• server aktsepteerib postitust TLS-i (STARTTLS) kasutades ja omab kehtivat sertifikaati.

MTA-STS eelised

MTA-STS kasutab tehnoloogiaid, mis on juba enamikes organisatsioonides rakendatud (SMTP+STARTTLS, HTTPS, DNS). Vastuvõtja poolel ei ole selle standardi rakendamiseks vaja spetsiaalset tarkvara.

MTA-STS puudused

Tuleb jälgida veebiserveri ja postiserveri sertifikaadi kehtivust, nime vastavust ning õigeaegset uuendamist. Sertifikaadiprobleemid võivad takistada posti kohaletoimetamist.

Saatja poolel on vaja MTA-d, mis toetab MTA-STS poliitikaid, hetkel MTA-STS ei toeta "karbist välja" MTA-d.

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

MTA-STS ei kaitse rünnakute eest, kus ründaja kasutab kehtivat sertifikaati. Enamikul juhtudel tähendab MitM ründamine serveri lähedal sertifikaadi väljaandmise võimalust. Sellist rünnakut saab tuvastada Certificate Transparency abil. Seetõttu leevendab MTA-STS, kuid ei kõrvalda täielikult liikluse pealtkuulamise võimalust.

Kaks viimast punkti teevad MTA-STS vähem kaitstud kui konkurentsivõimeline standard DANE SMTP jaoks (RFC 7672), kuid tehniliselt usaldusväärsemaks, st MTA-STS puhul on madal tõenäosus, et kiri ei toimetata kohale standardi rakendamise tõttu tekkinud tehniliste probleemide tõttu.

Konkurentsivõimeline standard — DANE

DANE kasutab DNSSEC-i sertifikaatide teabe avalikustamiseks ning ei nõua usaldust välistelt sertifitseerimiskeskustelt, mis on palju turvalisem. Kuid DNSSEC-i kasutamine toob sageli kaasa tehnilisi tõrkeid, kui tugineda mitme aasta statistikale (kuigi DNSSEC-i usaldusväärsuses ja tehnilises toetuses on üldiselt positiivne suundumus). DANE rakendamiseks SMTP-s peab saaja poole DNS-i tsooni jaoks olema DNSSEC, ning DANE jaoks on oluline NSEC/NSEC3 õige tugi, millega on DNSSEC-is süsteemseid probleeme.

Kui DNSSEC on valesti konfigureeritud, võib see põhjustada e-kirjade kohaletoimetamise tõrkeid, kui saatja toetab DANE-i, isegi kui vastuvõtva poolel pole sellest teadlikkust. Seetõttu, kuigi DANE on vanem ja turvalisem standard ning seda toetab juba mõni saatja serveri tarkvara, on selle levik seni olnud minimaalne, sest paljusid organisatsioone takistab selle rakendamine DNSSEC-i vajadus, mis on DANE-i kasutuselevõttu kõigil neil aastatel märgatavalt pidurdanud.

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

Kuidas on lood MTA-STS toetusega Mail.ru-s

Mail.ru on piisavalt ammu avaldanud MTA-STS poliitika kõigi peamiste domeenide jaoks. Praegu tegeleme standardi kliendi osa rakendamisega. Artikli kirjutamise ajal rakendatakse poliitikaid mitteblokeerivas režiimis (kui kohaletoimetamine on poliitika tõttu blokeeritud, siis saadetakse kiri «varu» serverisse, poliitikaid rakendamata), hiljem rakendame väikese osa väljaminevast SMTP liiklusest jaoks sundblokkeerivat režiimi ning järk-järgult toetatakse poliitika rakendamist 100% liiklusele.

Kes veel toetab standardit

Praegu avaldab poliitikaid MTA-STS umbes 0,05% aktiivsetest domeenidest, kuid nad kaitsevad siiski suurt osa e-posti liiklusest, kuna standardit toetavad suured mängijad — Google, Comcast ning osaliselt Verizon (AOL, Yahoo). Paljud teised e-posti teenused on teatanud, et standardi toetamist kavandatakse lähiajal.

Kuidas see mind mõjutab?

Ei midagi, kui teie domeen ei avalda MTA-STS poliitikat. Kui te avaldate poliitika, siis on teie meiliserveri kasutajate jaoks saadetud kirjad paremini kaitstud isikukaitse eest.

Kuidas rakendada MTA-STS?

MTA-STS tugi vastuvõtja poolel

Piisab poliitika avaldamisest HTTPS-i kaudu ja DNS-i kirjade konfigureerimisest, kehtiv sertifikaat peab olema ühelt usaldusväärselt CA-lt (võib kasutada Let's Encrypti) STARTTLS jaoks MTA-s (STARTTLS-d toetavad kõik kaasaegsed MTA-d), eritoe pool MTA-lt ei ole vajalik.

Samm-sammult näeb see välja järgmiselt:

1. Konfigureerige STARTTLS kasutatavas MTA-s (postfix, exim, sendmail, Microsoft Exchange jne).
2. Veenduge, et kasutate kehtivat sertifikaati (välja antud usaldusväärse CA poolt, mitte aegunud, sertifikaadi subjekt vastab MX-kirjale, mille kaudu teie domeeni jaoks postkasti saadetakse).
3. Konfigureerige TLS-RPT kirje, mille kaudu saadetakse poliitika täitmise aruanded (teenuste kaudu, mis toetavad raportite saatmist TLS). Näidis kirje (domeeni example.com jaoks):

   smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

   See kirje juhendab meilisaatjaid saatma statistikaaruandeid TLS-i kasutamise kohta SMTP-s aadressile tlsrpt@exmple.com.

   Jälgige aruandeid paar päeva, veenduge, et vigu pole.

4. Avaldage MTA-STS poliitika HTTPS-i kaudu. Poliitika avaldatakse tekstifailina rida lõppude CRLF kaudu.

   https://mta-sts.example.com/.well-known/mta-sts.txt
   

   Näidis poliitika:

   version: STSv1
   mode: enforce
   mx: mxs.mail.ru
   mx: emx.mail.ru
   mx: mx2.corp.mail.ru
   max_age: 86400
   

   Versioonipõld sisaldab poliitika versiooni (praegu see on STSv1), Mode määrab poliitika rakendamise režiimi, testing - testimisrežiim (poliitikat ei rakendata), enforce - "toimiv" režiim. Esmalt avaldage poliitika režiimiga: testing, kui poliitikaga ei esine probleeme testimisrežiimis, siis pärast mõnda aega võib lülituda režiimile: enforce.

   Mx-s määratakse kõigi meiliserverite nimekiri, mis võivad teie domeeni postkasti vastu võtta (iga server peab olema konfigureeritud sertifikaadiga, mis vastab mx-s määratud nimele). Max_age määrab poliitika vahemälu aja (korralikult mäletatud poliitikat rakendatakse isegi siis, kui ründaja blokeerib selle edastamise või rikub DNS-kirjad vahemälu aja jooksul; poliitika uuesti nõudmise signaalimiseks saab muuta mta-sts DNS kirjet).

5. Avaldage DNS-is TXT-kirje: 

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

   Id veldi võib kasutada suvalist identifikaatorit (nt ajatemplit), poliitika muutmisel peab see muutuma, see võimaldab saatjatel mõista, et tuleb uuesti küsida vahemälus hoitud poliitika (kui identifikaator erineb vahemälust).

MTA-STS toimetaja poolne tugi

Praegu on see nõrk, kuna standard on uus.

• Eximil ei ole sisseehitatud tuge, on olemas kolmanda osapoole skript https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfixil ei ole sisseehitatud tuge, on olemas kolmanda osapoole skript, millest on üksikasjalikult kirjutatud Habr's https://habr.com/en/post/424961/

Nõuanne 'kohustusliku TLS'i' kohta

Viimasel ajal pööravad regulaatorid tähelepanu posti turvalisusele (ja see on hea). Näiteks on DMARC kohustuslik kõigile riigiasutustele USA-s ja seda nõutakse üha sagedamini ka finantssektoris; reguleeritud valdkondades ulatub standardi levik 90% -ni. Praegu nõuavad mõned regulaatorid "kohustusliku TLS'i" rakendamist eraldi domeenide kaudu, kuid samas ei määratleta mehhanismi selle rakendamiseks ja praktikas rakendatakse see seade sageli viisil, mis ei kaitse isegi minimaalselt tegelike rünnakute eest, mida on juba ette nähtud sellistes mehhanismides nagu DANE või MTA-STS.

Kui regulaator nõuab "kohustusliku TLS'i" rakendamist eraldi domeenide kaudu, soovitame kaaluda MTA-STS või selle osalist analooge nagu kõige sobivamat mehhanismi, see eemaldab vajaduse teha turvalisi seadeid iga domeeni jaoks eraldi. Kui teil on raskusi MTA-STS kliendi osa rakendamisega (kuna protokoll ei ole veel laialdaselt toetatud, on need tõenäoliselt), võib soovitada sellist lähenemist:

1. Avaldage MTA-STS poliitika ja/või DANE kirjed (DANE on mõttekas lisada ainult siis, kui teie domeeni jaoks on juba lubatud DNSSEC, ja MTA-STS iga juhul), see kaitseb teie suunal liiklust ja vabastab vajadusest paluda teistel postiteenustel seadistada teie domeeni jaoks kohustuslikku TLS-i, kui postiteenus juba toetab MTA-STS ja/või DANE.
2. Suuremate postiteenuste jaoks rakendage iga domeeni jaoks eraldi transporti seadete kaudu MTA-STS «analoog», mis fikseerib MX, mida kasutatakse posti relayimiseks, ja nõuab selle TLS-sertifikaadi kohustuslikku kontrolli. Kui domeenid juba avaldavad MTA-STS poliitikat, saab seda tõenäoliselt teha valutult. Pelgalt TLSi kohustuslikku sisselülitamist domeeni jaoks ilma relay fikseerimise ja sertifikaadi kontrollita peetakse turvalisuse seisukohalt ebaefektiivseks ning see ei lisa midagi olemasolevatele STARTTLS mehhanismidele.

Allikas: habr.com