Ukratko, MTA-STS je način za dodatnu zaštitu e-pošte od presretanja (tj. napada čovjeka u sredini, poznatog kao MitM) kada se prenose između poslužitelja e-pošte. Djelomično rješava probleme naslijeđene arhitekture protokola e-pošte i opisan je u relativno nedavnom standardu RFC 8461. Mail.ru je prva velika usluga e-pošte na RuNetu koja implementira ovaj standard. I to je detaljnije opisano pod rezom.
Koji problem rješava MTA-STS?
Povijesno gledano, protokoli elektroničke pošte (SMTP, POP3, IMAP) prenosili su informacije u jasnom tekstu, što je omogućilo njihovo presretanje, primjerice, prilikom pristupa komunikacijskom kanalu.
Kako izgleda mehanizam za dostavu pisma od jednog korisnika do drugog:
Povijesno je MitM napad bio moguć na svim mjestima gdje cirkulira pošta.
RFC 8314 zahtijeva upotrebu TLS-a između korisničke aplikacije pošte (MUA) i poslužitelja pošte. Ako su vaš poslužitelj i aplikacije za poštu koje koristite usklađeni s RFC 8314, tada ste (uvelike) eliminirali mogućnost Man-in-the-Middle napada između korisnika i poslužitelja za poštu.
Slijedeći općeprihvaćene prakse (standardizirane prema RFC 8314) eliminiraju napad u blizini korisnika:
Mail.ru poslužitelji e-pošte bili su usklađeni s RFC 8314 čak i prije nego što je standard usvojen; zapravo, jednostavno bilježi već prihvaćene prakse i nismo morali ništa dodatno konfigurirati. Ali, ako vaš poslužitelj e-pošte i dalje dopušta korisnicima korištenje nesigurnih protokola, svakako implementirajte preporuke ovog standarda, jer Najvjerojatnije barem neki od vaših korisnika rade s poštom bez enkripcije, čak i ako je podržavate.
Klijent e-pošte uvijek radi s istim poslužiteljem e-pošte iste organizacije. I možete prisiliti sve korisnike da se povežu na siguran način, a zatim onemogućiti povezivanje nesigurnih korisnika (upravo to zahtijeva RFC 8314). Ovo je ponekad teško, ali izvedivo. Promet između poslužitelja pošte još je kompliciraniji. Poslužitelji pripadaju različitim organizacijama i često se koriste u načinu rada "postavi i zaboravi", što onemogućuje prebacivanje na sigurni protokol odjednom bez prekida veze. SMTP već dugo daje ekstenziju STARTTLS, koja omogućuje poslužiteljima koji podržavaju enkripciju prebacivanje na TLS. Ali napadač koji ima mogućnost utjecati na promet može "izrezati" informacije o podršci za ovu naredbu i natjerati poslužitelje da komuniciraju korištenjem običnog tekstualnog protokola (tzv. downgrade attack). 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 djelomično eliminira problem presretanja pisama između poslužitelja pošte, kada napadač ima mogućnost aktivnog utjecaja na promet. Ako domena primatelja objavljuje MTA-STS pravilo, a poslužitelj pošiljatelja podržava MTA-STS, poslat će e-poštu samo preko TLS veze, samo poslužiteljima definiranim pravilom i samo uz provjeru certifikata poslužitelja.
Zašto djelomič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-ova.
Kako radi MTA-STS
primalac
- Konfigurira STARTTLS podršku s valjanim certifikatom na poslužitelju e-pošte.
- Objavljuje MTA-STS politiku putem HTTPS-a; za objavu se koristi posebna mta-sts domena i posebna dobro poznata staza, npr.
https://mta-sts.mail.ru/.well-known/mta-sts.txt. Politika sadrži popis poslužitelja pošte (mx) koji imaju pravo primati poštu za ovu domenu. - Objavljuje poseban TXT zapis _mta-sts u DNS-u s verzijom pravila. Kada se pravilo promijeni, ovaj se unos mora ažurirati (ovo signalizira pošiljatelju da ponovno postavi upit o pravilu). Na primjer,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Отправитель
Pošiljatelj zahtijeva DNS zapis _mta-sts i, ako je dostupan, postavlja zahtjev za politiku putem HTTPS-a (provjera certifikata). Rezultirajuća politika se pohranjuje u predmemoriju (u slučaju da napadač blokira pristup njoj ili krivotvori DNS zapis).
Prilikom slanja pošte provjerava se da:
- poslužitelj na koji se isporučuje pošta je u politici;
- poslužitelj prihvaća 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 primatelja nije potrebna posebna softverska podrška za standard.
Nedostaci MTA-STS
Potrebno je pratiti valjanost certifikata web i mail servera, podudarnost imena i pravovremenu obnovu. Problemi s certifikatom rezultirat će nemogućnošću isporuke pošte.
Na strani pošiljatelja potreban je MTA s podrškom za pravila MTA-STS; trenutno MTA-STS nije podržan u MTA-u.
MTA-STS koristi popis pouzdanih korijenskih CA-ova.
MTA-STS ne štiti od napada u kojima napadač koristi važeći certifikat. U većini slučajeva MitM u blizini poslužitelja podrazumijeva mogućnost izdavanja certifikata. Takav napad može se otkriti pomoću Transparency certifikata. Stoga, općenito, MTA-STS ublažava, ali ne u potpunosti eliminira, mogućnost presretanja prometa.
Posljednje dvije točke čine MTA-STS manje sigurnim od konkurentskog DANE standarda za SMTP (RFC 7672), ali tehnički pouzdanijim, tj. za MTA-STS postoji mala vjerojatnost da pismo neće biti isporučeno zbog tehničkih problema uzrokovanih implementacijom standarda.
Natjecateljski standard - DANE
DANE koristi DNSSEC za objavljivanje informacija certifikata i ne zahtijeva povjerenje u vanjska tijela za izdavanje certifikata, što je mnogo sigurnije. No korištenje DNSSEC-a značajno češće dovodi do tehničkih kvarova, na temelju statistike tijekom nekoliko godina korištenja (iako općenito postoji pozitivan trend u pouzdanosti DNSSEC-a i njegove tehničke podrške). Za implementaciju DANE u SMTP na strani primatelja, prisutnost DNSSEC-a za DNS zonu je obavezna, a ispravna podrška za NSEC/NSEC3 neophodna je za DANE, s kojim postoje sistemski problemi u DNSSEC-u.
Ako DNSSEC nije ispravno konfiguriran, to može rezultirati neuspjehom isporuke pošte ako strana pošiljatelj podržava DANE, čak i ako strana primatelj ne zna ništa o tome. Stoga, unatoč činjenici da je DANE stariji i sigurniji standard i već je podržan u nekim poslužiteljskim softverima na strani pošiljatelja, zapravo njegova penetracija ostaje beznačajna, mnoge organizacije ga nisu spremne implementirati zbog potrebe implementacije DNSSEC-a, ovo je znatno usporilo implementaciju DANE svih ovih godina koliko je standard postojao.
DANE i MTA-STS nisu u sukobu jedan s drugim i mogu se koristiti zajedno.
Što je s MTA-STS podrškom u Mail.ru Mailu?
Mail.ru već neko vrijeme objavljuje MTA-STS politiku za sve glavne domene. Trenutno implementiramo klijentski dio standarda. U vrijeme pisanja, pravila se primjenjuju u načinu rada bez blokiranja (ako je isporuka blokirana pravilom, pismo će biti isporučeno putem "rezervnog" poslužitelja bez primjene pravila), a zatim će način blokiranja biti prisiljen za mali dio odlaznog SMTP prometa, postupno će za 100% prometa biti Podržana je provedba pravila.
Tko još podržava standard?
Do sada, MTA-STS politike objavljuju približno 0.05% aktivnih domena, ali, unatoč tome, već štite veliku količinu e-mail prometa, jer Standard podržavaju veliki igrači - Google, Comcast i dijelom Verizon (AOL, Yahoo). Mnoge druge poštanske usluge najavile su da će podrška za standard biti implementirana u bliskoj budućnosti.
Kako će to utjecati na mene?
Ne osim ako vaša domena ne objavi MTA-STS pravilo. Ako objavite pravilo, e-pošta za korisnike vašeg poslužitelja e-pošte bit će bolje zaštićena od presretanja.
Kako mogu implementirati MTA-STS?
MTA-STS podrška na strani primatelja
Dovoljno je objaviti politiku putem HTTPS-a i zapisa u DNS-u, konfigurirati važeći certifikat jednog od pouzdanih CA-ova (moguće je šifriranje Let's) za STARTTLS u MTA-u (STARTTLS je podržan u svim modernim MTA-ima), nema posebne podrške od Potreban je MTA.
Korak po korak, to izgleda ovako:
- Konfigurirajte STARTTLS u MTA-u koji koristite (postfix, exim, sendmail, Microsoft Exchange itd.).
- Provjerite koristite li važeći certifikat (izdao ga je pouzdan CA, nije istekao, predmet certifikata odgovara MX zapisu koji isporučuje poštu za vašu domenu).
- Konfigurirajte TLS-RPT zapis putem kojeg će se isporučivati izvješća aplikacije pravila (servisi koji podržavaju slanje TLS izvješća). Primjer unosa (za domenu example.com):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»Ovaj unos upućuje pošiljatelje pošte na slanje statističkih izvješća o upotrebi TLS-a u SMTP-u
[email protected].Pratite izvješća nekoliko dana kako biste bili sigurni da nema pogrešaka.
- Objavite pravilo MTA-STS putem HTTPS-a. Pravilo se objavljuje kao tekstualna datoteka s CRLF terminatorima reda prema lokaciji.
https://mta-sts.example.com/.well-known/mta-sts.txtPrimjer pravila:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400Polje verzije sadrži verziju pravila (trenutno
STSv1), Način postavlja način primjene pravila, testiranje — testni način (pravilo se ne primjenjuje), nametnuti — „borbeni” način. Prvo objavite pravilo s načinom: testiranje, ako nema problema s pravilom u testnom načinu, nakon nekog vremena možete prijeći na način: provedba.U mx-u je naveden popis svih poslužitelja e-pošte koji mogu prihvatiti poštu za vašu domenu (svaki poslužitelj mora imati konfiguriran certifikat koji odgovara imenu navedenom u mx-u). Max_age specificira vrijeme predmemoriranja pravila (jednom kada se zapamćeno pravilo primijeni čak i ako napadač blokira njegovu isporuku ili ošteti DNS zapise tijekom vremena predmemoriranja, možete signalizirati potrebu da ponovno zatražite pravilo promjenom mta-sts DNS snimiti).
- 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 ID polju; kada se pravilo promijeni, trebalo bi se promijeniti, to omogućuje pošiljateljima da razumiju da moraju ponovno zatražiti predmemorirano pravilo (ako se identifikator razlikuje od jedan u predmemoriji).
MTA-STS podrška na strani pošiljatelja
Zasad je s 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 pozornost 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 potrebniji u financijskom sektoru, s prodorom standarda koji doseže 90% u reguliranim područjima. Sada neki regulatori zahtijevaju implementaciju "obaveznog TLS-a" s pojedinačnim domenama, ali mehanizam za osiguravanje "obaveznog TLS-a" nije definiran iu praksi se ova postavka često implementira na način da ne štiti ni minimalno od stvarnih napada koji su već predviđeno u mehanizmima kao što su DANE ili MTA-STS.
Ako regulator zahtijeva implementaciju "obaveznog TLS-a" s odvojenim domenama, preporučujemo da razmotrite MTA-STS ili njegov djelomični analog kao najprikladniji mehanizam, eliminira potrebu za postavljanjem sigurnih postavki za svaku domenu zasebno. Ako imate poteškoća s implementacijom klijentskog dijela MTA-STS-a (sve dok protokol ne dobije široku podršku, vjerojatno 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 pitati druge e-mail usluge za konfiguraciju obveznog TLS-a za vašu domenu ako usluga pošte već podržava MTA-STS i/ili DANE.
- Za velike usluge e-pošte implementirajte "analog" MTA-STS-a kroz zasebne postavke prijenosa za svaku domenu, što će popraviti MX koji se koristi za prijenos pošte i zahtijevat će obaveznu provjeru TLS certifikata za to. Ako domene već objavljuju MTA-STS politiku, to se vjerojatno može učiniti bezbolno. Samo po sebi, omogućavanje obaveznog TLS-a za domenu bez popravljanja releja i provjere certifikata za njega je neučinkovito sa sigurnosne točke gledišta i ne dodaje ništa postojećim STARTTLS mehanizmima.
Izvor: www.habr.com