Kokkuvõttes on MTA-STS viis, kuidas kaitsta kirju edasi saatmise ajal rünnakute, nagu keskmes asuv (Man-in-the-Middle, aka MitM), eest. See lahendab osaliselt e-posti protokollide pärandlikke arhitektuurilisi probleeme ning on kirjas suhteliselt värskes standardis RFC 8461. Mail.ru on esimene suur e-posti teenus Runnets, mis selle standardi ellu viib. Täiendavat teavet leiate allolevast tekstist.

Millist probleemi lahendab MTA-STS?

Ajalooliselt edastasid e-posti protokollid (SMTP, POP3, IMAP) teavet avatud kujul, mis võimaldab selle pealtkuulamist, näiteks suhtlemiskanalile juurdepääsu korral.

Kuidas näeb välja kirjade saatmise mehhanism kasutaja poolt teisele:

Kuna ajalooliselt oli MitM rünnak võimalik kõikides kohtades, kus post liikles.

Standard RFC 8314 nõuab TLS-i kohustuslikku kasutamist kasutaja e-posti rakenduse (MUA) ja e-posti serveri vahel. Kui teie server ja kasutatavad e-posti rakendused vastavad RFC 8314-ile, siis olete suuresti kõrvaldada Man-in-the-Middle rünnakute võimaluse kasutaja ja e-posti serverite vahel.

Tavapäraste praktikate (standardiseeritud RFC 8314) järgimine kõrvaldab kasutaja lähedal aset leidvad rünnakud:

Mail.ru postiserverid vastasid RFC 8314-le juba enne standardi vastuvõtmist; tegelikult lihtsalt fikseerib see juba kehtestatud praktikad, seega ei pidanud me midagi täiendavalt seadistama. Kuid kui teie postiserver laseb endiselt kasutajatel siseneda ebausaldusväärsete protokollide kaudu, siis rakendage kindlasti selle standardi soovitusi, kuna tõenäoliselt töötab vähemalt osa teie kasutajatest mailiga, mis ei toeta krüpteerimist, isegi kui te seda toetate.

Postiklient suhtleb alati ühe ja sama organisatsiooni sama postiserveriga. Ühtlasi saab sundida kõiki kasutajaid turvaliselt ühenduma, muutes seejärel tehniliselt võimatuks ebaturvalisele ühendusele mineku (just seda nõuabki RFC 8314). See võib mõnikord olla keeruline, kuid on teostatav. Postiserverite vahel on olukord veelgi keerulisem. Serverid kuuluvad erinevatele organisatsioonidele ja neid kasutatakse sageli režiimis "pane ja unusta", mis muudab turvalisele protokollile ülemineku momentaalselt võimatuks ilma sidusust rikkumata. SMTP-s on juba ammu olemas laiendus STARTTLS, mis võimaldab krüpteerimise toetavatel serveritel üle minna TLS-ile. Kuid ründaja, kellel on võimalus liiklust mõjutada, võib "välja lõigata" teavet selle käsu toetamise kohta ja sundida servereid suhtlema tavalise tekstiprotokolli kaudu (nn downgrade attack — protokolli versiooni langetamise rünnak). Samuti ei kontrollita tavaliselt STARTTLS-i puhul sertifikaadi vastavust (usaldamatud sertifikaadid võivad kaitsta passiivsete rünnakute eest ja see pole halvem kui kirja saatmine avatud tekstina). Seetõttu kaitseb STARTTLS ainult passiivse pealtkuulamise eest.

MTA-STS vähendab osaliselt vahelesegamise probleemi e-kirjade edastamisel posti serverite vahel, kui ründajal on võimalus aktiivselt liiklust mõjutada. Kui sihtdomeen avaldab MTA-STS poliitika, ja saatja server toetab MTA-STS, saadetakse kiri ainult TLS-ühenduse kaudu, ainult poliitikas määratud serveritesse ja ainult serveri sertifikaadi kontrolliga.

Miks osaliselt? MTA-STS töötab ainult siis, kui mõlemad osalised on hoolitsenud selle standardi rakendamise eest, ning MTA-STS ei kaitse olukordade eest, kus ründajal on võimalus saada valideeritud domeeni sertifikaat ühes avalikus CA-s.

Kuidas MTA-STS töötab

Saaja

1. Seadistab STARTTLS toe valideeritud sertifikaadiga posti serveris. 
2. Avaldab HTTPS-i kaudu MTA-STS poliitika, avaldamiseks kasutatakse spetsiaalset domeeni mta-sts ja spetsiaalset well-known teed, näiteks https://mta-sts.mail.ru/.well-known/mta-sts.txt. Poliitika sisaldab nimekirja posti serveritest (mx), kellel on õigus saada posti sellele domeenile.
3. Avaldab spetsiaalse TXT-kirje _mta-sts DNS-is poliitika versiooniga. Kui poliitika muutub, tuleb see kirje uuendada (see annab saatjale signaali poliitika uuesti küsida). Näiteks, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Saatja

Saatja küsib DNS-kirjet _mta-sts, ja kui see on olemas, siis teeb ta poliitika küsitluse HTTPS kaudu (kontrollides sertifikaati). Saadud poliitika salvestatakse cache'i (juhuks, kui ründaja takistab sellele juurdepääsu või asendab DNS-kirje).

E-kirja saatmisel kontrollitakse, et:

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

MTA-STS eelised

MTA-STS kasutab tehnoloogiaid, mis on enamikus organisatsioonides juba rakendatud (SMTP+STARTTLS, HTTPS, DNS). Vastuvõtja poole rakendamiseks ei ole vajalik spetsiaalset tarkvara standardi toetamiseks.

MTA-STS puudused

On vajalik jälgida veebiserveri ja meilisüsteemi sertifikaadi kehtivust, nimede vastavust ning õigeaegset uuendamist. Probleemid sertifikaadiga võivad põhjustada kirjade edastamise võimatust.

Saaja poolel on vajalik MTA, mis toetab MTA-STS poliitikaid; hetkel ei toeta MTA-STS „karbist väljas“ MTA.

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

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

Kaks viimast punkti muudavad MTA-STS vähem kaitstuks võrreldes konkurentsivõimelise DANE standardiga SMTP jaoks (RFC 7672), kuid tehniliselt usaldusväärsemaks, st MTA-STS puhul on väike tõenäosus, et kiri ei toimi tehniliste probleemide tõttu, mis on tingitud standardi rakendamisest.

Konkurentsivõimeline standard on DANE

DANE kasutab DNSSEC-i sertifikaadi teabe avaldamiseks ja ei nõua usaldust välistelt tõenduspunktidelt, mis on oluliselt turvalisem. Kuid DNSSEC-i kasutamine toob statistika põhjal tihedamini kaasa tehnilisi tõrkeid, kuigi DNSSEC-i usaldusväärsuses ja tehnilises toetuses on üldiselt positiivne suundumus. DANE rakendamiseks SMTP-s vastu võtva poolel peab DNS-zona DNSSEC olema kohustuslik, ja DANE puhul on oluline NSEC/NSEC3 korrektne toetus, millega DNSSEC-il esineb süsteemseid probleeme.

Kui DNSSEC on valesti konfigureeritud, võib see põhjustada e-kirjade edastamise probleemide ilmnemist, kui saatja toetab DANE't, isegi kui vastuvõtja ei tea sellest midagi. Seetõttu, kuigi DANE on vanem ja turvalisem standard ning seda toetatakse juba mõnes saatja tarkvaras, jääb selle kasutuselevõtt siiski piiratud, kuna paljud organisatsioonid ei ole valmis seda rakendama DNSSEC-i vajaduse tõttu, mis on oluliselt aeglustanud DANE rakendamist kõigil neil aastatel, mil standard on olemas olnud.

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

Kuidas on lood MTA-STS toetusega Mail.ru postis?

Mail.ru on juba päris pikka aega avaldanud MTA-STS poliitikat kõigi oluliste domeenide kohta. Praegu viime läbi standardi kliendi poole rakendamist. Artikli kirjutamise hetkeks rakendatakse poliitikaid mittetakistavas režiimis (kui kohaletoimetamine on poliitika tõttu blokeeritud, toimetatakse kiri 'varuserveri' kaudu ilma poliitikaid rakendamata). Hiljem sunnitakse rakendama takistavat režiimi väikese osa saadetavast SMTP-liiklusest, järk-järgult rakendatakse poliitikaid 100% liiklusele.

Kes veel toetab standardit?

Praegu avaldavad MTA-STS poliitikat umbes 0,05% aktiivseid domeene, kuid hoolimata sellest kaitsevad nad juba suurt osa e-posti liiklusest, kuna standardit toetavad suured mängijad — Google, Comcast ja osaliselt Verizon (AOL, Yahoo). Paljud teised e-posti teenused on teatanud, et rakendavad standardi toetamist lähitulevikus.

Kuidas see mind mõjutab?

Ei mingil juhul, kui teie domeen ei avalda MTA-STS poliitikat. Kui avaldate poliitika, on teie meiliserveri kasutajate kirjad paremini kaitstud pealtkuulamise eest.

Kuidas rakendada MTA-STS?

MTA-STS-i tugi vastuvõtja poolel

Piisab poliitika avaldamisest HTTPS-i kaudu ja DNS-i rekordite konfigureerimisest, samuti kehtiva sertifikaadi seadistamisest usaldusväärselt CA-lt (nt Let's Encrypt) STARTTLS jaoks MTA-s (STARTTLS on toetatud kõigis kaasaegsetes MTA-des), erituge MTA-lt ei nõuta.

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

1. Konfigureerige STARTTLS kasutatavas MTA-s (postfix, exim, sendmail, Microsoft Exchange jne).
2. Veenduge, et kasutatakse kehtivat sertifikaati (välja antud usaldusväärse CA poolt, mitte aegunud, sertifikaadi subjekt vastab MX-rekordile, mille kaudu teie domeeni post on kohaletoimetatud).
3. Konfigureerige TLS-RPT rekord, kuhu saadetakse poliitika rakendamise aruanded (teenustele, mis toetavad raportite saatmist TLS). Näide rekordist (domeenile example.com):

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

   See rekord juhendab meilisaatjaid saatma statistilisi aruandeid TLS kasutamise kohta SMTP-s aadressile tlsrpt@example.com.

   Jälgige raportit paar päeva, veenduge, et vigu ei esine.

4. Avaldage MTA-STS poliitika HTTPS-i kaudu. Poliitika avaldatakse tekstifailina CRLF rida terminatsioonidega asukohas.

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

   Poliitika näide:

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

   Versioni väli sisaldab poliitika versiooni (hetkel see on STSv1), mode määrab poliitika rakendamise režiimi, testing — testrežiim (poliitikat ei rakendata), enforce — „töörühma” režiim. Esiteks avaldage poliitika mode: testing režiimis, kui testrežiimis pole poliitikaga probleeme, võite mõne aja pärast lülituda mode: enforce režiimi.

   Mx sisaldab nimekirja kõigist meiliserveritest, mis saavad teie domeeni jaoks postkasti (iga server peab olema konfigureeritud sertifikaadiga, mis vastab mx-s määratud nimele). Max_age määrab poliitika vahemälu kestuse (kord juba salvestatud poliitika rakendatakse isegi siis, kui ründaja blokeerib selle edastamise või rikutud DNS-kirjed vahemälu ajal, poliitika uuesti pärimise vajadust signaalitakse DNS-i mta-sts kirje muutmise kaudu).

5. Avaldage DNS-is TXT-kirje: 

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

   Id väljal võib kasutada suvalist identifikaatorit (nt ajatemplit), poliitika muutmisel peab see muutuma, et saatjad mõistaksid, et on vaja uuesti pärida vahemälustatud poliitikat (kui identifikaator erineb vahemälust).

MTA-STS tugi saatja poolel

Praegu on olukord kehv, kuna standard on uus.

• Exim - sisseehitatud tugi puudub, on saadaval kolmanda osapoole skript https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix - sisseehitatud tugi puudub, on saadaval kolmanda osapoole skript, millest on pikalt räägitud Habras https://habr.com/en/post/424961/

Lõppsõna „kohustuslik TLS” kohta

Viimasel ajal pööravad regulatiivsed ametiasutused tähelepanu postkasti turvalisusele (ja see on hea). Näiteks on DMARC kõigi Ameerika Ühendriikide riigiasutuste jaoks kohustuslik ja seda nõutakse üha sagedamini finantssektoris; reguleeritud valdkondades ulatub standardi levik 90%-ni. Praegu nõuavad mõned regulatoorsed organid „kohustusliku TLS” rakendamist eraldi domeenide puhul, kuid samas ei määratleta „kohustusliku TLS” tagamise mehhanismi ning praktikas rakendatakse seda sageli viisil, mis ei kaitse isegi minimaalselt reaalsete rünnakute eest, mis on juba ette nähtud sellistes mehhanismides nagu DANE või MTA-STS.

Kui regulatiivne organ nõuab 'mandatory TLS' rakendamist eraldi domeenide jaoks, soovitame kaaluda MTA-STS või tema osalist analooge kui kõige sobivamat mehhanismi. See elimineerib vajaduse teha iga domeeni jaoks eraldi turvasätteid. Kui teil on probleeme MTA-STS kliendipoolse rakendamisega (kuni protokoll ei saa laialdast toetust, on need tõenäoliselt olemas), võib soovitada järgmist lähenemist:

1. Avaldage MTA-STS poliitika ja/või DANE kirjed (DANE on mõttekas lisada vaid siis, kui teie domeeni jaoks on juba lubatud DNSSEC ning MTA-STS igal juhul), see kaitseb teie suunalist liiklust ja vabastab teid vajadusest paluda teistele meenusunditelt seadistada teie domeeni jaoks mandatory TLS, kui meenusund juba toetab MTA-STS ja/või DANE.
2. Suuremate postiteenuste puhul rakendage MTA-STS «analogi» iga domeeni jaoks eraldi transpordiseadete kaudu, mis fikseerivad kasutatava MX-i posti suunamiseks ja nõuavad selle jaoks TLS-sertifikaadi kohustuslikku kontrolli. Kui domeenid on juba avaldanud MTA-STS poliitika, on tõenäoliselt võimalik seda teha valutult. Ainuüksi TLS-i kohustuslikuks seadmine domeeni jaoks ilma edastamise fikseerimise ja selle jaoks sertifikaadi kontrollita ei ole turvalisuse seisukohalt efektiivne ja ei lisa midagi olemasolevatesse STARTTLS mehhanismidesse.

Allikas: habr.com