In corta, MTA-STS hè un modu per prutegge più e-mail da l'intercepzioni (vale à dì, attacchi man-in-the-middle aka MitM) quandu sò trasmessi trà i servitori di mail. Parzialmente risolve i prublemi architecturali legati di i protokolli di email è hè descrittu in u standard relativamente recente RFC 8461. Mail.ru hè u primu serviziu di mail maiò in RuNet per implementà stu standard. È hè descrittu in più detail sottu u cut.

Chì prublema risolve MTA-STS ?

Stòricamente, i protokolli di e-mail (SMTP, POP3, IMAP) trasmettenu infurmazione in testu chjaru, chì hà permessu di intercepte, per esempiu, quandu accede à un canale di cumunicazione.

Chì hè u meccanismo per trasmette una lettera da un utilizatore à l'altru cum'è:

Stòricamente, un attaccu MitM era pussibule in tutti i lochi induve u mail circula.

RFC 8314 richiede l'usu di TLS trà l'applicazione di l'utilizatori di mail (MUA) è u servitore di mail. Se u vostru servitore è l'applicazioni di mail chì utilizate sò conformi à RFC 8314, allora avete (in gran parte) eliminatu a pussibilità di attacchi Man-in-the-Middle trà l'utilizatori è i servitori di mail.

A seguita di pratiche generalmente accettate (standardizzate da RFC 8314) elimina l'attaccu vicinu à l'utilizatore:

I servitori di mail Mail.ru cumpiavanu cù RFC 8314 ancu prima chì u standard hè statu aduttatu; in fattu, solu catturà pratiche digià accettate, è ùn avemu micca bisognu di cunfigurà nunda di più. Ma, se u vostru servitore di mail permette ancu à l'utilizatori chì utilizanu protokolli insicuri, assicuratevi di implementà e raccomandazioni di stu standard, perchè Hè assai prubabile, almenu alcuni di i vostri utilizatori travaglianu cù mail senza criptografia, ancu s'ellu u sustene.

U cliente di mail sempre travaglia cù u stessu servitore di mail di a listessa urganizazione. È pudete furzà tutti l'utilizatori à cunnette in modu sicuru, è poi rende tecnicamente impussibile per l'utilizatori micca sicuri di cunnette (questu hè esattamente ciò chì RFC 8314 richiede). Questu hè qualchì volta difficiule, ma fattibile. U trafficu trà i servitori di mail hè sempre più cumplicatu. I servitori appartenenu à diverse urganisazioni è sò spessu usati in un modu "set and forget", chì rende impussibile di passà à un protokollu sicuru in una volta senza rompe a cunnessione. SMTP hà longu furnitu l'estensione STARTTLS, chì permette à i servitori chì supportanu a criptografia di cambià à TLS. Ma un attaccante chì hà a capacità di influenzà u trafficu pò "tagliate" l'infurmazioni nantu à u supportu per questu cumandamentu è furzà i servitori à cumunicà utilizendu un protokollu di testu chjaru (l'attaccu chjamatu downgrade). Per u listessu mutivu, STARTTLS di solitu ùn cuntrolla micca a validità di u certificatu (un certificatu micca fiduciale pò prutege contr'à attacchi passivi, è questu ùn hè micca peggiu di mandà un missaghju in testu chjaru). Dunque, STARTTLS pruteghja solu da l'eavesdropping passivi.

MTA-STS elimina parzialmente u prublema di intercepting lettere trà i servitori di mail, quandu l'attaccu hà a capacità di influenzà attivamente u trafficu. Se u duminiu di u destinatariu publica una pulitica MTA-STS è u servitore di u mittente supporta MTA-STS, mandarà solu l'email nantu à una cunnessione TLS, solu à i servitori definiti da a pulitica, è solu cù verificazione di u certificatu di u servitore.

Perchè parzialmente? MTA-STS funziona solu se i dui partiti anu curatu di implementà stu standard, è MTA-STS ùn pruteghja micca di scenarii in quale un attaccu hè capaci di ottene un certificatu di duminiu validu da unu di i CA publichi.

Cumu funziona MTA-STS

Ricettore

Configura u supportu STARTTLS cù un certificatu validu nantu à u servitore di mail.
Publica a pulitica MTA-STS via HTTPS; un duminiu speciale mta-sts è un percorsu speciale cunnisciutu sò usati per a publicazione, per esempiu https://mta-sts.mail.ru/.well-known/mta-sts.txt. A pulitica cuntene una lista di servitori di mail (mx) chì anu u dirittu di riceve mail per stu duminiu.
Publica un record TXT speciale _mta-sts in DNS cù a versione di pulitica. Quandu a pulitica cambia, sta entrata deve esse aghjurnata (questu signala à u mittente per ritruvà a pulitica). Per esempiu, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

U mittente

U mittente dumanda u registru DNS _mta-sts, è s'ellu hè dispunibule, fa una dumanda di pulitica via HTTPS (verificà u certificatu). A pulitica risultante hè in cache (in casu chì un attaccante blucca l'accessu à questu o spoofs u record DNS).

Quandu invià mail, hè verificatu chì:

u servitore à quale u mail hè mandatu hè in a pulitica;
u servitore accetta mail cù TLS (STARTTLS) è hà un certificatu validu.

Vantaghji di MTA-STS

MTA-STS usa tecnulugia chì sò digià implementate in a maiò parte di l'urganisazione (SMTP + STARTTLS, HTTPS, DNS). Per l'implementazione da u latu di u destinatariu, ùn hè micca necessariu un supportu software speciale per u standard.

I svantaghji di MTA-STS

Hè necessariu di monitorà a validità di u certificatu di u web è di u servitore di mail, a currispundenza di nomi, è u rinnuvamentu puntuale. I prublemi cù u certificatu saranu in l'impossibilità di spedinu u mail.

Da u latu di u mittente, un MTA cù supportu per e pulitiche MTA-STS hè necessariu; attualmente, MTA-STS ùn hè micca supportatu fora di a casella in u MTA.

MTA-STS usa una lista di CA radiche di fiducia.

MTA-STS ùn pruteghja micca da attacchi in quale l'attaccante usa un certificatu validu. In a maiò parte di i casi, MitM vicinu à u servitore implica a capacità di issuà un certificatu. Un tali attaccu pò esse rilevatu cù Certificate Transparency. Dunque, in generale, MTA-STS mitiga, ma ùn elimina micca cumplettamente, a pussibilità di intercepzioni di trafficu.

L'ultimi dui punti facenu MTA-STS menu sicuru ch'è u standard DANE cuncurrenti per SMTP (RFC 7672), ma più tecnicumente affidabile, i.e. per MTA-STS ci hè una prubabilità bassa chì a lettera ùn serà micca mandata per via di prublemi tecnichi causati da l'implementazione di u standard.

Standard cumpetizione - DANE

DANE usa DNSSEC per publicà l'infurmazioni di u certificatu è ùn hè micca bisognu di fiducia in l'autorità di certificati esterni, chì hè assai più sicura. Ma l'usu di DNSSEC significativamente più spessu porta à fallimenti tecnichi, basatu annantu à statistiche annantu à parechji anni di usu (ancu se ci hè in generale una tendenza pusitiva in l'affidabilità di DNSSEC è u so supportu tecnicu). Per implementà DANE in SMTP da u latu di u destinatariu, a presenza di DNSSEC per a zona DNS hè ubligatoriu, è u supportu currettu per NSEC / NSEC3 hè essenziale per DANE, cù quale ci sò prublemi sistemichi in DNSSEC.

Se DNSSEC ùn hè micca cunfiguratu currettamente, pò esse risultatu in fallimenti di spedizione di mail se u latu di l'inviu supporta DANE, ancu s'ellu u latu di riceve ùn sapi nunda. Dunque, malgradu u fattu chì DANE hè un standard più anticu è più sicuru è hè digià supportatu in certi software di u servitore da u latu di u mittente, in fattu a so penetrazione resta insignificante, assai urganisazioni ùn sò micca pronti à implementà per via di a necessità di implementà DNSSEC, questu hà rallentatu significativamente l'implementazione di DANE tutti quelli anni chì u standard esiste.

DANE è MTA-STS ùn sò micca cunflittu cù l'altri è ponu esse aduprati inseme.

Chì ci hè u supportu MTA-STS in Mail.ru Mail?

Mail.ru hà publicatu una pulitica MTA-STS per tutti i domini principali per un bellu pezzu. Attualmente implementemu a parte di u cliente di u standard. À u mumentu di a scrittura, e pulitiche sò applicate in un modu senza bloccu (se a consegna hè bluccata da una pulitica, a lettera serà mandata à traversu un servitore "spare" senza applicà pulitiche), u modu di bloccu serà furzatu per una piccula parte. di u trafficu SMTP in uscita, gradualmente per u 100% di u trafficu serà L'applicazione di e pulitiche hè supportata.

Quale altru sustene u standard?

Finu a ora, e pulitiche MTA-STS publicanu circa 0.05% di domini attivi, ma, in ogni modu, anu digià prutegge un grande volume di trafficu di mail, perchè U standard hè supportatu da i principali attori - Google, Comcast è in parte Verizon (AOL, Yahoo). Parechji altri servizii postali anu annunziatu chì u supportu per u standard serà implementatu in un futuru vicinu.

Cumu mi affetterà questu?

A menu chì u vostru duminiu publica una pulitica MTA-STS. Se pubblicate a pulitica, e-mail per l'utilizatori di u vostru servitore di mail seranu megliu prutetti da intercepzioni.

Cumu implementà MTA-STS?

Supportu MTA-STS da u latu destinatariu

Hè abbastanza per pubblicà a pulitica via HTTPS è registri in DNS, cunfigurà un certificatu validu da una di e CA di fiducia (Criptemu hè pussibule) per STARTTLS in u MTA (STARTTLS hè supportatu in tutti i MTA muderni), nisun supportu speciale da u MTA hè necessariu.

Passu à passu, pare cusì:

Configurate STARTTLS in u MTA chì site aduprate (postfix, exim, sendmail, Microsoft Exchange, etc.).
Assicuratevi di utilizà un certificatu validu (emissu da una CA di fiducia, micca scadutu, u sughjettu di u certificatu currisponde à u record MX chì furnisce mail per u vostru duminiu).
Configurate un registru TLS-RPT à traversu quale i rapporti di l'applicazioni di pulitica saranu consegnati (da servizii chì supportanu l'invio di rapporti TLS). Esempiu di entrata (per u duminiu example.com):
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Questa entrata urdina à i mittenti di mail per mandà rapporti statistici nantu à l'usu TLS in SMTP à [email protected].

Monitorate i rapporti per parechji ghjorni per assicurà chì ùn ci sò micca errori.
Publicate a pulitica MTA-STS nantu à HTTPS. A pulitica hè publicata cum'è un schedariu di testu cù terminatori di linea CRLF per locu.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Esempiu di pulitica:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
U campu di versione cuntene a versione di a pulitica (attualmente STSv1), Modu stabilisce u modu di applicazione di a pulitica, testing - modalità di prova (a pulitica ùn hè micca applicata), inforce - mode "combat". Prima publicà a pulitica cù u modu: teste, s'ellu ùn ci hè micca prublemi cù a pulitica in modu di prova, dopu un pocu tempu pudete cambià à u modu: enforce.

In mx, una lista di tutti i servitori di mail chì ponu accettà mail per u vostru duminiu hè specificatu (ogni servitore deve avè un certificatu cunfiguratu chì currisponde à u nome specificatu in mx). Max_age specifica u tempu di caching di a pulitica (una volta chì a pulitica ricordata serà applicata ancu s'ellu l'attaccante blucca a so consegna o corrompe i registri DNS durante u tempu di caching, pudete signalà a necessità di dumandà a pulitica di novu cambiendu u DNS mta-sts. record).
Publicà un record TXT in DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Un identificatore arbitrariu (per esempiu, un timestamp) pò esse usatu in u campu di l'id; quandu a pulitica cambia, duverebbe cambià, questu permette à i mittenti di capisce chì anu bisognu di dumandà à novu a pulitica in cache (se l'identificatore hè diversu da u cache unu).

Supportu MTA-STS da u latu di u mittente

Finu à avà hè male cun ella, perchè ... standard frescu.

Exim - senza supportu integratu, ci hè un script di terzu https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix - ùn ci hè micca supportu integratu, ci hè un script di terzu chì hè descrittu in dettagliu nantu à Habré https://habr.com/en/post/424961/

Cum'è una postfazione nantu à "TLS obligatoriu"

Ultimamente, i regulatori anu attentu à a sicurità di e-mail (è questu hè una bona cosa). Per esempiu, DMARC hè ubligatoriu per tutte l'agenzii di u guvernu in i Stati Uniti è hè sempre più necessariu in u settore finanziariu, cù a penetrazione di u standard chì righjunghji u 90% in i zoni regulati. Avà certi regulatori necessitanu l'implementazione di "TLS obligatoriu" cù duminii individuali, ma u mecanismu per assicurà "TLS obligatoriu" ùn hè micca definitu è in a pratica, sta paràmetra hè spessu implementata in una manera chì ùn pruteghja ancu minimamente da attacchi reali chì sò digià. prevista in meccanismi cum'è DANE o MTA-STS.

Se u regulatore richiede l'implementazione di "TLS obligatoriu" cù domini separati, ricumandemu di cunsiderà MTA-STS o u so analogu parziale cum'è u mecanismu più adattatu, elimina a necessità di fà paràmetri sicuri per ogni duminiu separatamente. Sì avete difficultà à implementà a parte di u cliente di MTA-STS (finu à chì u protokollu hà ricevutu un supportu generalizatu, assai prubabilmente), pudemu ricumandemu stu approcciu:

Publicà una pulitica MTA-STS è / o registri DANE (DANE hè sensu solu se DNSSEC hè digià attivatu per u vostru duminiu, è MTA-STS in ogni casu), questu prutege u trafficu in a vostra direzzione è eliminà a necessità di dumandà à altri servizii di mail. per cunfigurà TLS ubligatoriu per u vostru duminiu se u serviziu di mail supporta digià MTA-STS è / o DANE.
Per i grandi servizii di e-mail, implementate un "analogicu" di MTA-STS per mezu di paràmetri di trasportu separati per ogni duminiu, chì riparà u MX utilizatu per a trasmissione di mail è richiederà a verificazione obligatoria di un certificatu TLS per questu. Se i domini publicanu digià una pulitica MTA-STS, questu pò esse fattu senza dolore. Per sè stessu, l'attivazione di TLS obbligatoria per un duminiu senza risolve u relé è verificate u certificatu per questu hè inefficace da un puntu di vista di sicurità è ùn aghjunghje nunda à i meccanismi STARTTLS esistenti.

Source: www.habr.com

Mail.ru mail principia à applicà e pulitiche MTA-STS in modu di prova