Ukratko, MTA-STS je način dalje zaštite e-pošte od presretanja (tj. napada čovjeka u sredini aka MitM) kada se prenose između mail servera. Djelomično rješava stare arhitektonske probleme protokola e-pošte i opisan je u relativno nedavnom standardu RFC 8461. Mail.ru je prvi veliki servis pošte na RuNetu koji implementira ovaj standard. I to je detaljnije opisano pod rezom.
Koji problem rješava MTA-STS?
Istorijski gledano, protokoli e-pošte (SMTP, POP3, IMAP) su prenosili informacije u čistom tekstu, što je omogućavalo njihovo presretanje, na primjer, prilikom pristupa komunikacijskom kanalu.
Kako izgleda mehanizam za dostavu pisma od jednog korisnika drugom:
Istorijski gledano, MitM napad je bio moguć na svim mjestima gdje kruži pošta.
RFC 8314 zahtijeva korištenje TLS-a između korisničke aplikacije pošte (MUA) i servera pošte. Ako su vaš server i aplikacije za poštu koje koristite usklađeni sa RFC 8314, tada ste (u velikoj mjeri) eliminirali mogućnost napada čovjeka u sredini između korisnika i mail servera.
Praćenje opšte prihvaćenih praksi (standardizovanih RFC 8314) eliminiše napad u blizini korisnika:
Mail.ru serveri pošte bili su usklađeni sa RFC 8314 i prije nego što je standard usvojen; zapravo, on jednostavno bilježi već prihvaćene prakse i nismo morali ništa dodatno konfigurirati. Ali, ako vaš mail server i dalje dozvoljava korisnicima da koriste nesigurne protokole, obavezno implementirajte preporuke ovog standarda, jer Najvjerovatnije, barem neki od vaših korisnika rade s poštom bez enkripcije, čak i ako je podržavate.
Klijent pošte uvijek radi sa istim mail serverom iste organizacije. I možete natjerati sve korisnike da se povežu na bezbjedan način, a zatim onemogućite tehnički nemogućim povezivanje nebezbednih korisnika (to je upravo ono što zahteva RFC 8314). Ovo je ponekad teško, ali izvodljivo. Saobraćaj između mail servera je još složeniji. Serveri pripadaju različitim organizacijama i često se koriste u režimu „postavi i zaboravi“, što onemogućava prelazak na siguran protokol odjednom bez prekida veze. SMTP već dugo pruža STARTTLS ekstenziju, koja omogućava serverima koji podržavaju enkripciju da se prebace na TLS. Ali napadač koji ima mogućnost da utiče na saobraćaj može „izrezati“ informacije o podršci za ovu komandu i naterati servere da komuniciraju korišćenjem protokola običnog teksta (tzv. napad na downgrade). Iz istog razloga STARTTLS obično ne provjerava valjanost certifikata (nepouzdani certifikat može zaštititi od pasivnih napada, a to nije ništa gore od slanja poruke u čistom tekstu). Stoga STARTTLS štiti samo od pasivnog prisluškivanja.
MTA-STS djelimično eliminiše problem presretanja pisama između mail servera, kada napadač ima mogućnost da aktivno utiče na saobraćaj. Ako domen primaoca objavi MTA-STS politiku, a server pošiljaoca podržava MTA-STS, on će poslati e-poštu samo preko TLS veze, samo na servere definisane politikom i samo uz verifikaciju sertifikata servera.
Zašto djelimično? MTA-STS radi samo ako su se obje strane pobrinule za implementaciju ovog standarda, a MTA-STS ne štiti od scenarija u kojima napadač može dobiti važeći certifikat domene od jednog od javnih CA.
Kako funkcioniše MTA-STS
Primalac
- Konfigurira STARTTLS podršku s važećim certifikatom na mail serveru.
- Objavljuje MTA-STS politiku putem HTTPS-a; posebna mta-sts domena i posebna dobro poznata putanja se koriste za objavljivanje, npr.
https://mta-sts.mail.ru/.well-known/mta-sts.txt. Politika sadrži listu servera pošte (mx) koji imaju pravo da primaju poštu za ovu domenu. - Objavljuje poseban TXT zapis _mta-sts u DNS-u s verzijom politike. Kada se politika promijeni, ovaj unos se mora ažurirati (ovo signalizira pošiljaocu da ponovo postavi upit za politiku). Na primjer,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Pošiljalac
Pošiljalac traži _mta-sts DNS zapis, i ako je dostupan, postavlja zahtjev politike putem HTTPS-a (provjera certifikata). Rezultirajuća politika se kešira (u slučaju da joj napadač blokira pristup ili lažira DNS zapis).
Prilikom slanja pošte provjerava se da:
- server na koji se isporučuje pošta je u politici;
- server prihvata poštu koristeći TLS (STARTTLS) i ima važeći certifikat.
Prednosti MTA-STS
MTA-STS koristi tehnologije koje su već implementirane u većini organizacija (SMTP+STARTTLS, HTTPS, DNS). Za implementaciju na strani primaoca nije potrebna posebna softverska podrška za standard.
Nedostaci MTA-STS
Neophodno je pratiti validnost sertifikata web i mail servera, podudarnost imena i pravovremeno obnavljanje. Problemi sa certifikatom će rezultirati nemogućnošću isporuke pošte.
Na strani pošiljaoca je potreban MTA s podrškom za MTA-STS politike; trenutno MTA-STS nije podržan izvan kutije u MTA.
MTA-STS koristi listu pouzdanih root CA.
MTA-STS ne štiti od napada u kojima napadač koristi važeći certifikat. U većini slučajeva, MitM u blizini servera podrazumijeva mogućnost izdavanja certifikata. Takav napad može se otkriti korištenjem Transparentnosti certifikata. Stoga, općenito gledano, MTA-STS ublažava, ali ne eliminira u potpunosti, mogućnost presretanja saobraćaja.
Poslednje dve tačke čine MTA-STS manje sigurnim od konkurentskog DANE standarda za SMTP (RFC 7672), ali tehnički pouzdanijim, tj. za MTA-STS postoji mala vjerovatnoća da pismo neće biti dostavljeno zbog tehničkih problema uzrokovanih implementacijom standarda.
Konkurentski standard - DANE
DANE koristi DNSSEC za objavljivanje informacija o certifikatima i ne zahtijeva povjerenje u eksterna ovlaštenja za izdavanje certifikata, što je mnogo sigurnije. Ali upotreba DNSSEC-a značajno češće dovodi do tehničkih kvarova, na osnovu statistike tokom nekoliko godina korištenja (iako općenito postoji pozitivan trend u pouzdanosti DNSSEC-a i njegove tehničke podrške). Za implementaciju DANE-a u SMTP na strani primaoca, prisustvo DNSSEC-a za DNS zonu je obavezno, a ispravna podrška za NSEC/NSEC3 je neophodna za DANE, sa kojim postoje sistemski problemi u DNSSEC-u.
Ako DNSSEC nije ispravno konfigurisan, to može dovesti do neuspjeha isporuke pošte ako strana koja šalje podržava DANE, čak i ako strana koja prima ništa ne zna o tome. Stoga, uprkos činjenici da je DANE stariji i sigurniji standard i da je već podržan u nekim serverskim softverima na strani pošiljaoca, u stvari njegova penetracija ostaje beznačajna, mnoge organizacije nisu spremne da ga implementiraju zbog potrebe implementacije DNSSEC-a, ovo je značajno usporilo implementaciju DANE-a svih onih godina koliko standard postoji.
DANE i MTA-STS nisu međusobno konfliktni i mogu se koristiti zajedno.
Šta je sa MTA-STS podrškom u Mail.ru Mail-u?
Mail.ru već duže vrijeme objavljuje MTA-STS politiku za sve glavne domene. Trenutno implementiramo klijentski dio standarda. U vrijeme pisanja, politike se primjenjuju u neblokirajućem načinu (ako je isporuka blokirana polisom, pismo će biti isporučeno preko “rezervnog” servera bez primjene politika), tada će način blokiranja biti prisiljen u malom dijelu odlaznog SMTP saobraćaja, postepeno će za 100% saobraćaja biti Podržana je primena politika.
Ko još podržava standard?
Do sada, MTA-STS politike objavljuju oko 0.05% aktivnih domena, ali, ipak, već štite veliki obim mail saobraćaja, jer Standard podržavaju glavni igrači - Google, Comcast i dijelom Verizon (AOL, Yahoo). Mnoge druge poštanske službe najavile su da će podrška za standard biti implementirana u bliskoj budućnosti.
Kako će to uticati na mene?
Ne osim ako vaša domena ne objavi MTA-STS politiku. Ako objavite politiku, e-poruke za korisnike vašeg mail servera bit će bolje zaštićene od presretanja.
Kako da implementiram MTA-STS?
MTA-STS podrška na strani primaoca
Dovoljno je objaviti politiku putem HTTPS-a i zapisa u DNS-u, konfigurirati važeći certifikat od jednog od pouzdanih CA (Hajde da šifriramo) za STARTTLS u MTA-u (STARTTLS je podržan u svim modernim MTA-ovima), nema posebne podrške od strane MTA je obavezan.
Korak po korak, to izgleda ovako:
- Konfigurišite STARTTLS u MTA koji koristite (postfix, exim, sendmail, Microsoft Exchange, itd.).
- Uvjerite se da koristite važeći certifikat (izdao ga je pouzdani CA, nije istekao, predmet certifikata odgovara MX zapisu koji dostavlja poštu za vašu domenu).
- Konfigurirajte TLS-RPT zapis preko kojeg će se dostavljati izvještaji o aplikaciji politike (po uslugama koje podržavaju slanje TLS izvještaja). Primjer unosa (za domen example.com):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»Ovaj unos upućuje pošiljaoce pošte da šalju statističke izvještaje o korištenju TLS-a u SMTP-u
[email protected].Pratite izvještaje nekoliko dana kako biste bili sigurni da nema grešaka.
- Objavite MTA-STS politiku preko HTTPS-a. Politika se objavljuje kao tekstualna datoteka sa CRLF terminatorima linija prema lokaciji.
https://mta-sts.example.com/.well-known/mta-sts.txtPrimjer politike:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400Polje verzija sadrži verziju politike (trenutno
STSv1), Mode postavlja režim aplikacije politike, testiranje — testni režim (politika se ne primenjuje), sprovođenje — „borbeni“ režim. Prvo objavite politiku sa načinom: testiranje, ako nema problema sa politikom u test modu, nakon nekog vremena možete se prebaciti na mod: enforce.U mx-u je navedena lista svih servera pošte koji mogu prihvatiti poštu za vašu domenu (svaki server mora imati konfiguriran certifikat koji odgovara imenu specificiranom u mx). Max_age specificira vrijeme keširanja politike (kada će se zapamćena politika primijeniti čak i ako napadač blokira njenu isporuku ili pokvari DNS zapise tokom vremena keširanja, možete signalizirati potrebu da ponovo zatražite politiku promjenom mta-sts DNS-a rekord).
- Objavite TXT zapis u DNS-u:
_mta-sts.example.com. TXT “v=STS1; id=someid;”Proizvoljni identifikator (na primjer, vremenska oznaka) može se koristiti u polju id; kada se politika promijeni, ona bi se trebala promijeniti, što omogućava pošiljaocima da shvate da moraju ponovo zatražiti keširanu politiku (ako se identifikator razlikuje od keširana jedna).
MTA-STS podrška na strani pošiljaoca
Do sada je sa njom loše, jer... svježi standard.
- Exim - nema ugrađene podrške, postoji skripta treće strane
- Postfix - nema ugrađene podrške, postoji skripta treće strane koja je detaljno opisana na Habréu
Kao pogovor o "obaveznom TLS-u"
U posljednje vrijeme regulatori obraćaju pažnju na sigurnost e-pošte (i to je dobra stvar). Na primjer, DMARC je obavezan za sve vladine agencije u Sjedinjenim Državama i sve je više potreban u finansijskom sektoru, s penetracijom standarda koji dostiže 90% u reguliranim područjima. Sada neki regulatori zahtijevaju implementaciju “obaveznog TLS-a” sa pojedinačnim domenima, ali mehanizam za osiguravanje “obaveznog TLS-a” nije definiran i u praksi se ova postavka često implementira na način koji čak ni minimalno ne štiti od stvarnih napada koji su već predviđeno u mehanizmima kao što su DANE ili MTA-STS.
Ako regulator zahtijeva implementaciju “obaveznog TLS-a” sa zasebnim domenima, preporučujemo da se MTA-STS ili njegov parcijalni analog uzme u obzir kao najpogodniji mehanizam, to eliminiše potrebu za postavljanjem sigurnih postavki za svaki domen posebno. Ako imate poteškoća s implementacijom klijentskog dijela MTA-STS-a (sve dok protokol ne dobije široku podršku, najvjerovatnije hoće), možemo preporučiti ovaj pristup:
- Objavite MTA-STS politiku i/ili DANE zapise (DANE ima smisla samo ako je DNSSEC već omogućen za vašu domenu, a MTA-STS u svakom slučaju), to će zaštititi promet u vašem smjeru i eliminirati potrebu da pitate druge usluge e-pošte da konfigurišete obavezni TLS za vašu domenu ako servis pošte već podržava MTA-STS i/ili DANE.
- Za velike usluge e-pošte implementirajte “analog” MTA-STS kroz odvojene transportne postavke za svaki domen, što će popraviti MX koji se koristi za prenošenje pošte i zahtijevat će obaveznu verifikaciju TLS certifikata za njega. Ako domeni već objavljuju MTA-STS politiku, to se vjerovatno može učiniti bezbolno. Samo po sebi, omogućavanje obaveznog TLS-a za domenu bez fiksiranja releja i verifikacije certifikata za njega je neefikasno sa sigurnosne tačke gledišta i ne dodaje ništa postojećim STARTTLS mehanizmima.
izvor: www.habr.com