Pe scurt, MTA-STS este o modalitate de a proteja suplimentar e-mailurile împotriva interceptării (adică atacuri de tip MitM) în timpul transportului între serverele de e-mail. Acesta rezolvă parțial problemele arhitecturale tradiționale ale protocoalelor de e-mail și este descris în standardul relativ recent RFC 8461. Mail.ru este primul serviciu major de e-mail din Runet care implementează acest standard. O prezentare mai detaliată urmează mai jos.
Ce problemă rezolvă MTA-STS?
Istoric, protocoalele de e-mail (SMTP, POP3, IMAP) au transmis informațiile în mod deschis, ceea ce permite interceptarea acestora, de exemplu, în cazul accesului la canalul de comunicație.
Cum arată mecanismul de livrare a unui e-mail de la un utilizator la altul:
Istoric, atacurile MitM erau posibile în toate punctele prin care trecea e-mailul.
Standardul RFC 8314 impune utilizarea obligatorie a TLS între aplicația de e-mail a utilizatorului (MUA) și serverul de e-mail. Dacă serverul dumneavoastră și aplicațiile de e-mail utilizate respectă RFC 8314, atunci ați eliminat (în mare parte) posibilitatea atacurilor Man-in-the-Middle între utilizator și serverele de e-mail.
Respectarea practicilor generale acceptate (standardizate în RFC 8314) elimină atacurile aproape de utilizator:
Serverele de e-mail Mail.ru respectau RFC 8314 încă înainte de adoptarea standardului, de fapt, acesta doar consemnează practicile deja acceptate și nu a fost necesar să facem ajustări suplimentare. Dar, dacă serverul dumneavoastră de e-mail permite în continuare utilizatorilor să folosească protocoale nesigure, implementați neapărat recomandările acestui standard, deoarece este foarte probabil ca cel puțin o parte dintre utilizatorii dumneavoastră să folosească e-mailul fără criptare, chiar dacă o susțineți.
Clientul de email lucrează întotdeauna cu același server de email al aceleași organizații. Se poate forța toți utilizatorii să se conecteze în mod sigur, după care să se facă imposibilă conexiunea nesigură (aceasta este ceea ce necesită RFC 8314). Este uneori complicat, dar realizabil. Traficul între serverele de email este și mai complex. Serverele aparțin unor organizații diferite și sunt adesea folosite în modul "am instalat și am uitat", ceea ce face imposibilă o trecere instantanee la un protocol sigur fără a compromite coerența. În SMTP există de multă vreme o extensie STARTTLS, care permite serverelor care suportă criptarea să treacă la TLS. Dar un atacator care poate influența traficul poate "tăia" informația despre suportul acestei comenzi și poate forța serverele să comunice prin protocol de text obișnuit (așa-numita atac downgrade — atac asupra versiunii protocolului). Din același motiv, pentru STARTTLS de obicei nu se verifică conformitatea certificatului (un certificat nevalidat poate proteja împotriva atacurilor pasive, iar asta nu este mai rău decât trimiterea unui mesaj în text clar). Prin urmare, STARTTLS protejează doar împotriva ascultării pasive.
MTA-STS elimine parțial problema interceptării mesajelor între serverele de email, atunci când un atacator are posibilitatea de a influența activ traficul. Dacă domeniul destinatarului publică o politică MTA-STS și serverul expeditorului suportă MTA-STS, acesta va trimite mesajul doar printr-o conexiune TLS, doar către serverele specificate în politică și doar cu verificarea certificatului serverului.
De ce parțial? MTA-STS funcționează doar dacă ambele părți se preocupă de implementarea acestui standard, iar MTA-STS nu protejează împotriva scenariilor în care atacatorul poate obține un certificat valid pentru domeniu de la una dintre autoritățile de certificare publice.
Cum funcționează MTA-STS
Destinatarul
- Configurează suportul STARTTLS cu un certificat valid pe serverul de email.
- Publică prin HTTPS politica MTA-STS, pentru publicare folosind un domeniu special mta-sts și un path well-known special, de exemplu
https://mta-sts.mail.ru/.well-known/mta-sts.txt. Politica conține o listă de servere de email (mx) care au dreptul să primească emailuri pentru acest domeniu. - Publică un înregistrare TXT specială _mta-sts în DNS cu versiunea politicii. Atunci când politica se modifică, această înregistrare trebuie actualizată (acest lucru semnalizează expeditorului că trebuie să refacă cererea de politică). De exemplu,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Expeditor
Expeditorul solicită înregistrarea DNS _mta-sts, iar dacă aceasta există, face o cerere de politică prin HTTPS (verificând certificatul). Politica obținută este cache-uită (în cazul în care atacatorul blochează accesul la aceasta sau înlocuiește înregistrarea DNS).
Atunci când se trimite un e-mail, se verifică că:
- serverul la care se livrează e-mailul este în politică;
- serverul acceptă e-mailuri utilizând TLS (STARTTLS) și are un certificat valid.
Avantajele MTA-STS
MTA-STS folosește tehnologii care sunt deja implementate în majoritatea organizațiilor (SMTP+STARTTLS, HTTPS, DNS). Pentru implementare pe partea destinatarului nu este necesară o suport software special pentru standard.
Dezavantajele MTA-STS
Este necesar să urmăriți validitatea certificatului serverului web și de e-mail, conformitatea numelui, actualizarea la timp. Problemele cu certificatul vor duce la imposibilitatea livrării e-mailului.
Pe partea expeditorului, este necesar un MTA cu suport pentru politicile MTA-STS, în prezent nu există suport nativ pentru MTA-STS în MTA.
MTA-STS utilizează o listă de CA rădăcină de încredere.
MTA-STS nu protejează împotriva atacurilor în care atacatorul utilizează un certificat valid. În majoritatea cazurilor, un MitM apropiat de server implică posibilitatea de a emite un certificat. Un astfel de atac poate fi detectat datorită Certificate Transparency. Prin urmare, în general, MTA-STS mitigează, dar nu elimină complet posibilitatea interceptării traficului.
Cele două ultime puncte fac MTA-STS mai puțin sigur decât standardul concurent DANE pentru SMTP (RFC 7672), dar mai tehnic fiabil, adică pentru MTA-STS probabilitatea ca un e-mail să nu fie livrat din cauza problemelor tehnice cauzate de implementarea standardului este scăzută.
Standardul concurent – DANE
DANE folosește DNSSEC pentru a publica informații despre certificate și nu necesită încredere în autoritățile de certificare externe, ceea ce este mult mai sigur. Însă utilizarea DNSSEC duce, în mod semnificativ mai des, la defecțiuni tehnice, dacă ne bazăm pe statistici din câțiva ani de utilizare (deși fiabilitatea DNSSEC și suportul tehnic, în general, prezintă o tendință pozitivă). Pentru a implementa DANE în SMTP pe partea destinatarului, prezența DNSSEC pentru zona DNS este obligatorie, iar pentru DANE este esențial suportul corect pentru NSEC/NSEC3, cu care DNSSEC are probleme sistemice.
Dacă DNSSEC este configurat greșit, acest lucru poate duce la refuzuri în livrarea e-mailurilor, în cazul în care partea expeditorului suportă DANE, chiar dacă partea destinatară nu știe nimic despre acesta. Prin urmare, deși DANE este un standard mai vechi și mai sigur, deja acceptat în unele software-uri server pe partea expeditorului, de fapt, penetrarea sa rămâne nesemnificativă, multe organizații nu sunt pregătite să-l implementeze din cauza necesității de a implementa DNSSEC, ceea ce a încetinit semnificativ adoptarea DANE în toți acești ani de existență a standardului.
DANE și MTA-STS nu se împiedică reciproc și pot fi utilizate împreună.
Ce suport are MTA-STS în Mail.ru?
Mail.ru publică de mult timp politica MTA-STS pentru toate domeniile principale. Acum ne ocupăm de implementarea părții client a standardului. La momentul redactării articolului, politicile sunt aplicate în mod non-blocant (în cazul în care livrarea este blocată de politică, e-mailul va fi livrat printr-un server „de rezervă” fără aplicarea politicilor), apoi va fi forțat un mod blocant pentru o mică parte din traficul SMTP de ieșire, gradual pentru 100% din trafic va fi susținută aplicarea politicilor.
Cine mai suportă standardul?
În prezent, politicile MTA-STS sunt publicate de aproximativ 0,05% din domeniile active, dar, cu toate acestea, acestea protejează deja un volum mare de trafic poștal, deoarece standardul este susținut de jucători mari — Google, Comcast și parțial Verizon (AOL, Yahoo). Multe alte servicii de poștă au anunțat că suportul pentru standard va fi implementat în viitorul apropiat.
Cum mă va afecta acest lucru?
Niciunul, dacă domeniul dumneavoastră nu publică o politică MTA-STS. Dacă publicați o politică, atunci mesajele pentru utilizatorii serverului dumneavoastră de email vor fi mai bine protejate împotriva interceptării.
Cum să implementez MTA-STS?
Suport pentru MTA-STS pe partea de destinatar
Este suficient să publicați o politică prin HTTPS și să configurați înregistrările DNS, să aveți un certificat valid de la unul dintre CA-uri de încredere (puteți folosi Let's Encrypt) pentru STARTTLS în MTA (STARTTLS este suportat în toate MTA-urile moderne), nu este necesară o asistență specială din partea MTA.
Pas cu pas, arată astfel:
- Configurați STARTTLS în MTA-ul utilizat (postfix, exim, sendmail, Microsoft Exchange etc.).
- Asigurați-vă că se folosește un certificat valid (întocmit de un CA de încredere, netrecut de termen, subiectul certificatului corespunde înregistrării MX pe care se livrează emailurile pentru domeniul dumneavoastră).
- Configurați înregistrarea TLS-RPT, pe care se vor livra rapoartele de aplicare a politicilor (servicii care suportă trimiterea rapoartelor TLS). Exemplu de înregistrare (pentru domeniul example.com):
smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"Această înregistrare instruiește expeditorii de email să trimită rapoarte statistice despre utilizarea TLS în SMTP la adresa
tlsrpt@exmple.com.Urmăriți rapoartele câteva zile, asigurați-vă că nu există erori.
- Publicați politica MTA-STS prin HTTPS. Politica este publicată ca un fișier text cu terminatori de linie CRLF la locație.
https://mta-sts.example.com/.well-known/mta-sts.txtExemplu de politică:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400Câmpul version conține versiunea politicii (în prezent aceasta este
STSv1), Modu stabilește modul de aplicare a politicii, testing — modul de testare (politica nu se aplică), enforce — modul 'de producție'. Publicați mai întâi politica cu mode: testing, dacă nu apar probleme cu politica în modul de testare, după o vreme puteți trece la mode: enforce.În mx se specifică lista tuturor serverelor de email care pot primi emailuri pentru domeniul dumneavoastră (fiecare server trebuie să aibă un certificat configurat care corespunde numelui specificat în mx). Max_age stabilește timpul de cache al politicii (o politică deja memorată va fi aplicată chiar dacă atacatorul blochează livrarea sa sau alterează înregistrările DNS pe parcursul timpului de cache, semnalizarea necesității de a solicita din nou politica poate fi realizată prin modificarea înregistrării MTA-STS în DNS).
- Publicați înregistrarea TXT în DNS:
_mta-sts.example.com. TXT "v=STS1; id=someid;"În câmpul id, se poate folosi un identificator personalizat (de exemplu, un timestamp); atunci când politica se schimbă, identificatorul trebuie să se schimbe, ceea ce permite expeditorilor să înțeleagă că este necesar să reîntrebe politica cache-uită (dacă identificatorul diferă de cel cache-uit).
Suport pentru MTA-STS pe partea expeditorului
Momentan este slab, deoarece standardul este nou.
- Exim - nu are suport încorporat, există un script de terță parte
- Postfix - nu are suport încorporat, există un script despre care s-a discutat detaliat pe Habr
Ca un epilog despre „mandatory TLS”
Recent, reglatorii acordă atenție securității e-mailului (și este un lucru bun). De exemplu, DMARC este obligatoriu pentru toate instituțiile guvernamentale din SUA și este tot mai frecvent solicitat în domeniul financiar; în domeniile reglementate, penetrarea standardului atinge 90%. Acum, unii reglatorii cer implementarea „mandatory TLS” cu domenii separate, dar mecanismul de asigurare a „mandatory TLS” nu este definit și, în practică, această setare este adesea implementată în moduri care nu protejează chiar și minim împotriva atacurilor reale, care sunt deja prevăzute în mecanisme precum DANE sau MTA-STS.
Dacă reglatorul solicită implementarea „mandatory TLS” cu domenii separate, recomandăm să luați în considerare MTA-STS sau un echivalent parțial ca cel mai potrivit mecanism; acesta elimină necesitatea de a face setări-secure pentru fiecare domeniu în parte. Dacă aveți dificultăți în implementarea părții clientului MTA-STS (până când protocolul nu va obține un suport larg, acestea vor fi probabil), se poate recomanda această abordare:
- Publicați politica MTA-STS și/sau înregistrările DANE (DANE are sens să adăugați doar dacă pentru domeniul dvs. este deja activat DNSSEC, iar MTA-STS în orice caz); aceasta va proteja traficul către dvs. și va elimina necesitatea de a solicita altor servicii de e-mail să configureze mandatory TLS pentru domeniul dvs., dacă serviciul de e-mail suportă deja MTA-STS și/sau DANE.
- Pentru serviciile mari de mail, implementați un «analog» MTA-STS prin setări de transport separate pentru fiecare domeniu, care vor fixa MX utilizat pentru redirecționarea e-mailurilor și vor solicita verificarea obligatorie a certificatului TLS. Dacă domeniile publică deja o politică MTA-STS, acest lucru se poate face probabil fără probleme. Activarea TLS obligatoriu pentru un domeniu fără fixarea relay-ului și verificarea certificatului nu este eficientă din perspectiva securității și nu adaugă nimic la mecanismele existente STARTTLS.
Sursa: habr.com
