Livrare criptată: TLS, MTA-STS și DANE

Modulul 5: Reputație și furnizorii mari · Timp de citire: 10 minute

Obiectiv de învățare: După această lecție veți putea explica modul în care serverele de e-mail criptează comunicarea între ele, de ce acest lucru nu este impus implicit, și ce schimbă MTA-STS, TLS-RPT și DANE în această privință. Veți putea căuta și citi înregistrările respective.

Concepte esențiale: STARTTLS între servere, criptare oportunistă, atac de tip downgrade, MTA-STS (RFC 8461), înregistrarea _mta-sts, fișier de politică, modul testing/enforce/none, TLS-RPT (RFC 8460), înregistrarea _smtp._tls, DANE pentru SMTP (RFC 7672), înregistrare TLSA, DNSSEC

Două tipuri de conexiuni

În lecția 1.4 a fost vorba despre conexiunea dintre programul dumneavoastră de e-mail și serverul de e-mail al furnizorului dumneavoastră: portul 587 cu STARTTLS, sau 465 cu TLS direct, cu autentificare. Acolo aveți dumneavoastră controlul. Programul dumneavoastră știe ce server se așteaptă să găsească, verifică certificatul și refuză conectarea dacă ceva nu este în regulă.

Această lecție se referă la pasul următor: conexiunea dintre serverul expeditor și serverul destinatar, pe portul 25. Aceasta se desfășoară diferit.

Oportunist: criptare atunci când este posibil

Când un server livrează e-mail, se conectează la MX-ul destinatarului. După EHLO, verifică dacă serverul destinatar oferă STARTTLS. Dacă da, trece la o conexiune criptată. Dacă nu, livrează pur și simplu mesajul necriptat.

Acest lucru se numește criptare oportunistă: se criptează atunci când este posibil, altfel nu. Iar de cele mai multe ori serverul expeditor nu verifică strict certificatul. Un certificat expirat sau autosemnat nu constituie, în acest caz, un motiv pentru a opri livrarea.

De ce astfel? Pentru că e-mailul trebuie să funcționeze mereu, inclusiv cu servere vechi. Un expeditor nu poate ști dacă un destinatar ar trebui să aibă TLS. Acest lucru face posibile două tipuri de atacuri:

1. Downgrade. Cineva care poate modifica traficul pe parcurs elimină cuvântul STARTTLS din răspunsul destinatarului. Expeditorul crede că nu există criptare și livrează necriptat. Atacatorul citește mesajul.
2. MX fals. Cineva care poate falsifica răspunsuri DNS indică propriul server drept MX. Deoarece certificatul nu este verificat, expeditorul nu observă nimic.

În prezent, aproape toate serverele mari de e-mail criptează, iar Gmail solicită expeditorilor să folosească TLS (lecția 5.3). Dar „de obicei criptat” este altceva decât „întotdeauna și cu serverul corect”. Pentru aceasta există două soluții: MTA-STS și DANE. Ambele sunt configurate de destinatar: prin intermediul lor anunțați că mesajele către domeniul dumneavoastră trebuie întotdeauna criptate, către un server cu un certificat valid.

MTA-STS: politică prin intermediul unei pagini web

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) funcționează cu două componente.

O înregistrare TXT care indică faptul că există o politică:

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261108T120000;"

Și un fișier de politică într-un loc fix, accesibil prin https cu un certificat valid:

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

Partea inteligentă: un expeditor reține politica pe durata max_age. Un atacator care ulterior elimină cuvântul STARTTLS sau indică un MX fals este astfel demascat: politica spune că este obligatorie criptarea și care sunt serverele valide. La prima conexiune (înainte ca politica să fie cunoscută), MTA-STS nu oferă protecție; acesta este punctul slab cunoscut.

Un exemplu real este gmail.com: înregistrarea TXT _mta-sts.gmail.com există, iar fișierul de politică de la https://mta-sts.gmail.com/.well-known/mta-sts.txt are setat mode: enforce.

TLS-RPT: rapoarte despre criptarea eșuată

Cu MTA-STS pe enforce, mesajele pot rămâne blocate dacă este ceva în neregulă cu certificatul dumneavoastră. Doriți să aflați acest lucru. Pentru aceasta există TLS-RPT (RFC 8460):

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"

Expeditorii care acceptă TLS-RPT (printre alții Google și Microsoft) trimit apoi zilnic un raport în format JSON: câte conexiuni au reușit și care au eșuat, cu motivul (de exemplu, un certificat expirat sau un nume care nu figurează în politică). La fel ca în cazul rapoartelor DMARC (lecția 4.5), puteți lăsa prelucrarea acestora unui serviciu de raportare.

Ordinea la implementare: mai întâi TLS-RPT, apoi MTA-STS pe testing, câteva săptămâni de citit rapoarte, și abia după aceea enforce. Acest lucru seamănă cu linia de abordare treptată de la DMARC: mai întâi observare, apoi strictețe.

DANE: certificatul în DNS, securizat cu DNSSEC

DANE (DNS-based Authentication of Named Entities) abordează problema altfel. Plasați în DNS o înregistrare TLSA pentru fiecare server MX, cu o amprentă a certificatului sau a cheii:

_25._tcp.mx1.example.com.  3600  IN  TLSA  3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5

_25._tcp înseamnă: pentru SMTP pe portul 25. Cele trei numere indică modul în care trebuie citită valoarea. Pentru serverele de e-mail, 3 1 1 este cel mai folosit: „aceasta este amprenta SHA-256 a cheii publice a exact acestui server”. Apare și 2 1 1: atunci conține amprenta unui certificat intermediar.

Un expeditor care acceptă DANE vede înregistrarea TLSA, impune criptarea și verifică dacă certificatul serverului corespunde. Dacă nu corespunde, nu livrează mesajul.

De ce este DANE sigur împotriva răspunsurilor DNS falsificate? Pentru că funcționează numai cu DNSSEC (cursul DNS, lecția 8.1). Fără un lanț DNSSEC valid, înregistrările TLSA sunt ignorate. Acesta este imediat pragul de acces: atât domeniul dumneavoastră (pentru MX), cât și zona serverului de e-mail trebuie să fie semnate.

DANE nu are o slăbiciune de tipul „prima dată” precum MTA-STS, și este mult folosit, de exemplu în Țările de Jos și Germania. internet.nl testează acest aspect. Microsoft acceptă DANE pentru e-mailul primit în Exchange Online. De asemenea, serverele MX ale internet.nl au înregistrări TLSA.

Capcană: dacă înlocuiți certificatul unui server de e-mail care folosește DANE cu o cheie nouă, înregistrarea TLSA trebuie modificată odată cu acesta, și anume dinainte: mai întâi se adaugă noua înregistrare, se așteaptă până expiră TTL-ul, abia apoi se pune în uz noua cheie. Altfel, expeditorii cu DANE vor refuza mesajele dumneavoastră. La 3 1 1, acest lucru contează numai atunci când se schimbă cheia, nu la fiecare reînnoire cu aceeași cheie.

MTA-STS sau DANE?

Le puteți folosi în paralel. RFC 8461 spune că un expeditor care acceptă DANE dă prioritate DANE dacă există înregistrări TLSA valide.

Cine configurează acest lucru?

Acest lucru se configurează pentru e-mailul primit pe domeniul dumneavoastră. Dacă e-mailul dumneavoastră rulează la o companie de găzduire sau un serviciu de e-mail, depinde de acel furnizor:

• DANE este posibil numai dacă furnizorul publică înregistrări TLSA pentru serverele sale de e-mail și domeniul dumneavoastră are DNSSEC. La WebOké, de exemplu, puteți activa DANE în același loc ca DNSSEC (consultați articolul internet.nl de mai jos); la alți furnizori funcționează similar sau este configurat implicit.
• MTA-STS îl puteți configura uneori chiar dumneavoastră, dar atunci mta-sts.example.com trebuie să fie un site web cu un certificat valid și trebuie să cunoașteți numele serverelor MX ale furnizorului dumneavoastră.
• TLS-RPT îl puteți configura întotdeauna chiar dumneavoastră: este doar o înregistrare TXT cu o adresă de raportare.

Pentru e-mailul dumneavoastră trimis nu trebuie să faceți nimic: serverul furnizorului dumneavoastră decide dacă respectă MTA-STS și DANE ale destinatarilor.

Rezumat

• Între serverele de e-mail, TLS este implicit oportunist: criptat atunci când este posibil, fără verificare strictă a certificatului. Acest lucru face posibile downgrade-ul și MX-ul fals.
• MTA-STS: TXT _mta-sts plus fișier de politică la https://mta-sts.<domeniu>/.well-known/mta-sts.txt; modul testing sau enforce.
• TLS-RPT: TXT _smtp._tls cu o adresă de raportare, pentru rapoarte zilnice despre criptarea eșuată.
• DANE: înregistrare TLSA la _25._tcp.<server-mx>, funcționează numai cu DNSSEC și protejează și prima conexiune.
• Implementați ca la DMARC: mai întâi rapoarte (TLS-RPT, testing), apoi strictețe.

Quiz

Exercițiu

Exercițiu Z5.4: Căutarea MTA-STS, TLS-RPT și DANE. Căutați pentru gmail.com înregistrarea MTA-STS și înregistrarea TLS-RPT, deschideți fișierul de politică și completați modul (enforce, testing sau none). Căutați apoi, pentru un server MX al internet.nl, înregistrarea TLSA la _25._tcp.<server-mx> și completați primele trei numere ale uneia dintre înregistrări. Opțional: aceleași întrebări pentru propriul dumneavoastră domeniu (acolo răspunsul poate fi „niciuna”). Programul interoghează totul în timp real și compară.

Lectură suplimentară

Pașii din aceste articole sunt valabili pentru panourile WebOké; la alți furnizori funcționează similar.

• Lista de verificare Internet.nl
• Ce este DNSSEC?
• Curs gratuit de DNS 8.1: DNSSEC pe înțelesul tuturor
• internet.nl, testați-vă e-mailul (test independent al STARTTLS, DANE și altele): https://internet.nl/
• RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE pentru SMTP)