Skratka, MTA-STS je način za dodatno zaščito e-pošte pred prestrezanjem (tj. napadi človek-v-sredi ali MitM), ko se prenašajo med poštnimi strežniki. Delno rešuje podedovane arhitekturne probleme e-poštnih protokolov in je opisan v razmeroma novem standardu RFC 8461. Mail.ru je prva večja poštna storitev v RuNetu, ki izvaja ta standard. In podrobneje je opisano pod rezom.

Kakšno težavo rešuje MTA-STS?

V zgodovini so e-poštni protokoli (SMTP, POP3, IMAP) prenašali informacije v obliki čistega besedila, kar je omogočalo njihovo prestrezanje, na primer pri dostopu do komunikacijskega kanala.

Kako izgleda mehanizem za dostavo pisma od enega uporabnika do drugega:

Zgodovinsko gledano je bil napad MitM možen na vseh mestih, kjer kroži pošta.

RFC 8314 zahteva uporabo TLS med poštno uporabniško aplikacijo (MUA) in poštnim strežnikom. Če so vaš strežnik in poštne aplikacije, ki jih uporabljate, skladne z RFC 8314, potem ste (v veliki meri) odpravili možnost napadov Man-in-the-Middle med uporabnikom in poštnimi strežniki.

Sledenje splošno sprejetim praksam (standardiziranim z RFC 8314) odpravi napad v bližini uporabnika:

Poštni strežniki Mail.ru so bili skladni z RFC 8314 že pred sprejetjem standarda, pravzaprav preprosto zajema že sprejete prakse in nam ni bilo treba ničesar dodatno konfigurirati. Če pa vaš poštni strežnik še vedno dovoljuje uporabnikom uporabo nevarnih protokolov, upoštevajte priporočila tega standarda, ker Najverjetneje vsaj nekateri vaši uporabniki delajo s pošto brez šifriranja, tudi če ga podpirate.

Poštni odjemalec vedno deluje z istim poštnim strežnikom iste organizacije. Vse uporabnike lahko prisilite, da se povežejo na varen način, nato pa nezaščitenim uporabnikom tehnično onemogočite povezavo (točno to zahteva RFC 8314). To je včasih težko, a izvedljivo. Promet med poštnimi strežniki je še bolj zapleten. Strežniki pripadajo različnim organizacijam in se pogosto uporabljajo v načinu »nastavi in pozabi«, zaradi česar je nemogoče preklopiti na varen protokol naenkrat brez prekinitve povezljivosti. SMTP že dolgo zagotavlja razširitev STARTTLS, ki strežnikom, ki podpirajo šifriranje, omogoča preklop na TLS. Toda napadalec, ki ima možnost vplivanja na promet, lahko "izreže" informacije o podpori za ta ukaz in prisili strežnike, da komunicirajo po protokolu z navadnim besedilom (tako imenovani napad na znižanje). Iz istega razloga STARTTLS običajno ne preverja veljavnosti potrdila (nezaupanja vredno potrdilo lahko ščiti pred pasivnimi napadi in to ni nič slabše od pošiljanja sporočila v čistem besedilu). Zato STARTTLS ščiti samo pred pasivnim prisluškovanjem.

MTA-STS delno odpravi problem prestrezanja pisem med poštnimi strežniki, ko ima napadalec možnost aktivnega vplivanja na promet. Če prejemnikova domena objavi pravilnik MTA-STS in pošiljateljev strežnik podpira MTA-STS, bo e-pošto poslal samo prek povezave TLS, le strežnikom, ki jih določa pravilnik, in samo s preverjanjem potrdila strežnika.

Zakaj delno? MTA-STS deluje le, če sta obe strani poskrbeli za implementacijo tega standarda, MTA-STS pa ne ščiti pred scenariji, v katerih lahko napadalec pridobi veljavno potrdilo domene od enega od javnih CA.

Kako deluje MTA-STS

prejemnik

Konfigurira podporo STARTTLS z veljavnim potrdilom na poštnem strežniku.
Objavi pravilnik MTA-STS prek HTTPS; za objavo se uporablja posebna domena mta-sts in posebna znana pot, npr. https://mta-sts.mail.ru/.well-known/mta-sts.txt. Politika vsebuje seznam poštnih strežnikov (mx), ki imajo pravico prejemati pošto za to domeno.
Objavi poseben zapis TXT _mta-sts v DNS z različico pravilnika. Ko se pravilnik spremeni, je treba ta vnos posodobiti (to signalizira pošiljatelju, da znova poizveduje po pravilniku). na primer _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Pošiljatelj

Pošiljatelj zahteva zapis DNS _mta-sts in, če je na voljo, naredi zahtevo po pravilniku prek HTTPS (preverjanje potrdila). Nastali pravilnik se shrani v predpomnilnik (v primeru, da napadalec blokira dostop do njega ali ponaredi zapis DNS).

Pri pošiljanju pošte se preveri:

strežnik, na katerega se dostavlja pošta, je v pravilniku;
strežnik sprejema pošto z uporabo TLS (STARTTLS) in ima veljavno potrdilo.

Prednosti MTA-STS

MTA-STS uporablja tehnologije, ki so že implementirane v večini organizacij (SMTP+STARTTLS, HTTPS, DNS). Za implementacijo na strani prejemnika ni potrebna posebna programska podpora za standard.

Slabosti MTA-STS

Potrebno je spremljati veljavnost certifikata spletnega in poštnega strežnika, ujemanje imen in pravočasno obnavljanje. Težave s potrdilom povzročijo, da pošte ne bo mogoče dostaviti.

Na strani pošiljatelja je potreben MTA s podporo za pravilnike MTA-STS; MTA-STS trenutno ni podprt v MTA.

MTA-STS uporablja seznam zaupanja vrednih korenskih CA.

MTA-STS ne ščiti pred napadi, pri katerih napadalec uporablja veljavno potrdilo. V večini primerov MitM v bližini strežnika pomeni možnost izdaje potrdila. Takšen napad je mogoče zaznati s preglednostjo potrdila. Zato na splošno MTA-STS omili, vendar ne odpravi popolnoma možnosti prestrezanja prometa.

Zaradi zadnjih dveh točk je MTA-STS manj varen od konkurenčnega standarda DANE za SMTP (RFC 7672), a bolj tehnično zanesljiv, tj. za MTA-STS obstaja majhna verjetnost, da pismo ne bo dostavljeno zaradi tehničnih težav, ki jih povzroča implementacija standarda.

Tekmovalni standard - DANE

DANE uporablja DNSSEC za objavo informacij o potrdilih in ne zahteva zaupanja v zunanje overitelje potrdil, kar je veliko bolj varno. Toda uporaba DNSSEC bistveno pogosteje vodi do tehničnih okvar, kar temelji na statistiki večletne uporabe (čeprav je v splošnem pozitiven trend zanesljivosti DNSSEC in njegove tehnične podpore). Za implementacijo DANE v SMTP na strani prejemnika je obvezna prisotnost DNSSEC za cono DNS, pravilna podpora za NSEC/NSEC3 pa je bistvenega pomena za DANE, s katerim so v DNSSEC sistemske težave.

Če DNSSEC ni pravilno konfiguriran, lahko povzroči napake pri dostavi pošte, če pošiljateljska stran podpira DANE, tudi če prejemna stran o tem ne ve ničesar. Torej, kljub dejstvu, da je DANE starejši in bolj varen standard in je že podprt v nekaterih strežniških programih na strani pošiljatelja, dejansko ostaja njegova prodornost nepomembna, številne organizacije ga niso pripravljene implementirati zaradi potrebe po implementaciji DNSSEC, to je bistveno upočasnilo implementacijo DANE vsa leta, odkar je standard obstajal.

DANE in MTA-STS nista v nasprotju drug z drugim in ju je mogoče uporabljati skupaj.

Kaj je s podporo MTA-STS v Mail.ru Mail?

Mail.ru že nekaj časa objavlja pravilnik MTA-STS za vse glavne domene. Trenutno izvajamo odjemalski del standarda. V času pisanja se pravilniki uporabljajo v načinu brez blokiranja (če pravilnik blokira dostavo, bo pismo dostavljeno prek »rezervnega« strežnika brez uporabe pravilnikov), nato pa bo za majhen del vsiljen način blokiranja odhodnega prometa SMTP, postopoma za 100 % prometa bo podprto uveljavljanje pravilnikov.

Kdo še podpira standard?

Politike MTA-STS do zdaj objavljajo približno 0.05 % aktivnih domen, vendar kljub temu varujejo že velik obseg poštnega prometa, saj Standard podpirajo glavni igralci - Google, Comcast in delno Verizon (AOL, Yahoo). Številne druge poštne storitve so napovedale, da bodo podporo standardu uvedli v bližnji prihodnosti.

Kako bo to vplivalo name?

Ne, razen če vaša domena objavi pravilnik MTA-STS. Če objavite pravilnik, bodo e-poštna sporočila za uporabnike vašega poštnega strežnika bolje zaščitena pred prestrezanjem.

Kako implementiram MTA-STS?

Podpora MTA-STS na strani prejemnika

Dovolj je, da objavite pravilnik prek HTTPS in zapisov v DNS, konfigurirate veljavno potrdilo enega od zaupanja vrednih CA (možno je šifriranje Let's) za STARTTLS v MTA (STARTTLS je podprt v vseh sodobnih MTA), ni posebne podpore s strani Potreben je MTA.

Korak za korakom je videti takole:

Konfigurirajte STARTTLS v MTA, ki ga uporabljate (postfix, exim, sendmail, Microsoft Exchange itd.).
Prepričajte se, da uporabljate veljavno potrdilo (ki ga je izdal zaupanja vreden CA, ni poteklo, predmet potrdila se ujema z zapisom MX, ki dostavlja pošto za vašo domeno).
Konfigurirajte zapis TLS-RPT, prek katerega bodo dostavljena poročila aplikacije pravilnika (storitve, ki podpirajo pošiljanje poročil TLS). Primer vnosa (za domeno example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Ta vnos naroči pošiljateljem pošte, naj pošljejo statistična poročila o uporabi TLS v SMTP [email protected].

Več dni spremljajte poročila, da se prepričate, da ni napak.
Objavite pravilnik MTA-STS prek HTTPS. Pravilnik je objavljen kot besedilna datoteka z zaključki vrstic CRLF glede na lokacijo.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Primer politike:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Polje za različico vsebuje različico pravilnika (trenutno STSv1), Način nastavi način uporabe pravilnika, testiranje — testni način (pravilnik se ne uporablja), uveljavitev — »bojni« način. Najprej objavite pravilnik z načinom: testiranje, če v testnem načinu ni težav s pravilnikom, lahko čez nekaj časa preklopite na način: uveljavi.

V mx je določen seznam vseh poštnih strežnikov, ki lahko sprejmejo pošto za vašo domeno (vsak strežnik mora imeti konfigurirano potrdilo, ki se ujema z imenom, podanim v mx). Max_age določa čas predpomnjenja pravilnika (ko bo shranjen pravilnik uporabljen, tudi če napadalec med časom predpomnjenja blokira njegovo dostavo ali poškoduje zapise DNS, lahko sporočite, da morate znova zahtevati pravilnik, tako da spremenite mta-sts DNS zapis).
Objavite zapis TXT v DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
V polju id lahko uporabite poljuben identifikator (na primer časovni žig); ko se pravilnik spremeni, bi se moral spremeniti, kar pošiljateljem omogoča, da razumejo, da morajo znova zahtevati predpomnjeni pravilnik (če je identifikator drugačen od predpomnilnik).

Podpora MTA-STS na strani pošiljatelja

Zaenkrat je z njo slabo, ker ... svež standard.

Exim - ni vgrajene podpore, obstaja skript tretje osebe https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - ni vgrajene podpore, obstaja skript tretje osebe, ki je podrobno opisan na Habréju https://habr.com/en/post/424961/

Kot spremno besedo o "obveznem TLS"

V zadnjem času so regulatorji pozorni na varnost elektronske pošte (in to je dobro). DMARC je na primer obvezen za vse vladne agencije v Združenih državah in je vedno bolj potreben v finančnem sektorju, pri čemer prodor standarda dosega 90 % na reguliranih območjih. Zdaj nekateri regulatorji zahtevajo implementacijo “obveznega TLS” s posameznimi domenami, vendar mehanizem za zagotavljanje “obveznega TLS” ni definiran in v praksi je ta nastavitev pogosto implementirana na način, ki niti minimalno ne ščiti pred resničnimi napadi, ki so že na voljo v mehanizmih, kot sta DANE ali MTA-STS.

Če regulator zahteva izvajanje "obveznega TLS" z ločenimi domenami, priporočamo, da razmislite o MTA-STS ali njegovem delnem analogu kot najprimernejšem mehanizmu, saj odpravlja potrebo po varnih nastavitvah za vsako domeno posebej. Če imate težave pri implementaciji odjemalskega dela MTA-STS (dokler protokol ne dobi široke podpore, jo najverjetneje bo), lahko priporočamo ta pristop:

Objavite pravilnik MTA-STS in/ali zapise DANE (DANE je smiseln samo, če je DNSSEC že omogočen za vašo domeno, MTA-STS pa v vsakem primeru), to bo zaščitilo promet v vaši smeri in odpravilo potrebo po vprašanjih drugih poštnih storitev da konfigurirate obvezni TLS za vašo domeno, če poštna storitev že podpira MTA-STS in/ali DANE.
Za velike e-poštne storitve implementirajte "analog" MTA-STS prek ločenih nastavitev prenosa za vsako domeno, ki bo popravil MX, ki se uporablja za posredovanje pošte, in bo zanj zahteval obvezno preverjanje potrdila TLS. Če domene že objavljajo politiko MTA-STS, je to mogoče narediti brez težav. Omogočanje obveznega TLS za domeno brez popravka releja in preverjanja potrdila zanj je samo po sebi neučinkovito z varnostnega vidika in ne dodaja ničesar k obstoječim mehanizmom STARTTLS.

Vir: www.habr.com

Pošta Mail.ru začne uporabljati politike MTA-STS v testnem načinu