Consegna cifrata: TLS, MTA-STS e DANE
Modulo 5: Reputazione e i grandi provider · Tempo di lettura: 10 minuti
Obiettivo della lezione: dopo questa lezione saprà spiegare come i server di posta si cifrano reciprocamente, perché questo non è imponibile per default, e cosa cambiano MTA-STS, TLS-RPT e DANE in merito. Saprà cercare e leggere i relativi record.
Concetti chiave: STARTTLS tra server, cifratura opportunistica, attacco di downgrade, MTA-STS (RFC 8461), record _mta-sts, file di policy, modalità testing/enforce/none, TLS-RPT (RFC 8460), record _smtp._tls, DANE per SMTP (RFC 7672), record TLSA, DNSSEC
Due tipi di connessione
Nella lezione 1.4 si è parlato della connessione tra il Suo programma di posta e il server di posta del Suo fornitore: porta 587 con STARTTLS, oppure 465 con TLS diretto, con autenticazione. Lì ha il controllo Lei stesso. Il Suo programma sa quale server si aspetta, controlla il certificato e rifiuta di connettersi se qualcosa non torna.
Questa lezione riguarda il passo successivo: la connessione tra il server mittente e il server ricevente, sulla porta 25. Lì le cose funzionano diversamente.
Opportunistica: cifrare quando possibile
Quando un server consegna la posta, si connette al MX del destinatario. Dopo EHLO verifica se il server ricevente offre STARTTLS. Se sì, passa a una connessione cifrata. Se no, consegna semplicemente la posta in chiaro.
Questo si chiama cifratura opportunistica: si cifra quando è possibile, altrimenti no. E di solito il server mittente non controlla il certificato in modo rigoroso. Un certificato scaduto o autofirmato non è quindi un motivo per interrompere la connessione.
Perché funziona così? Perché la posta deve sempre continuare a funzionare, anche con server vecchi. Un mittente non può sapere se un destinatario debba avere TLS. Questo rende possibili due attacchi:
- Downgrade. Chi riesce a manipolare il traffico in transito rimuove la parola
STARTTLSdalla risposta del destinatario. Il mittente crede che non ci sia cifratura e consegna in chiaro. L'aggressore legge il contenuto. - MX falso. Chi riesce a falsificare le risposte DNS indica un proprio server come MX. Poiché il certificato non viene controllato, il mittente non se ne accorge.
Oggi quasi tutti i grandi server di posta cifrano, e Gmail richiede ai mittenti di usare TLS (lezione 5.3). Ma "di solito cifrato" è diverso da "sempre e con il server giusto". Per questo esistono due soluzioni: MTA-STS e DANE. Entrambe vengono impostate dal destinatario: con esse Lei comunica che la posta verso il Suo dominio deve sempre essere cifrata, verso un server con un certificato valido.
MTA-STS: policy tramite una pagina web
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) funziona con due componenti.
Un record TXT che dichiara l'esistenza di una policy:
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20261108T120000;"E un file di policy in una posizione fissa, raggiungibile via https con un certificato valido:
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| Riga | Significato |
|---|---|
mode: enforce | Consegnare solo tramite TLS con un certificato valido presso uno dei server MX indicati. Se non riesce, non consegnare (rimane in coda) |
mode: testing | Consegnare come sempre, ma segnalare i problemi tramite TLS-RPT |
mode: none | Non c'è (più) alcuna policy |
mx: | I nomi dei server MX che devono portare il certificato; è ammesso un *. all'inizio |
max_age: | Per quanto tempo (in secondi) un mittente può ricordare la policy |
id= nel record TXT | Un numero di versione. Se modifica la policy, cambi anche l'id, in modo che i mittenti recuperino di nuovo il file |
L'aspetto intelligente: un mittente ricorda la policy per la durata di max_age. Un aggressore che in seguito rimuova la parola STARTTLS o fornisca un MX falso viene così smascherato: la policy dichiara che la cifratura è obbligatoria e quali server sono validi. Alla primissima connessione (prima che la policy sia nota) MTA-STS non protegge; è il punto debole noto.
Un esempio reale è gmail.com: il record TXT _mta-sts.gmail.com esiste, e il file di policy su https://mta-sts.gmail.com/.well-known/mta-sts.txt ha mode: enforce.
TLS-RPT: rapporti sulla cifratura fallita
Con MTA-STS impostato su enforce, la posta può rimanere bloccata se qualcosa non va con il Suo certificato. Lei vuole saperlo. Per questo esiste TLS-RPT (RFC 8460):
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"I mittenti che supportano TLS-RPT (tra cui Google e Microsoft) inviano quindi quotidianamente un rapporto in formato JSON: quante connessioni sono riuscite e quali sono fallite, con il motivo (ad esempio un certificato scaduto o un nome non presente nella policy). Come per i rapporti DMARC (lezione 4.5), può farli elaborare da un servizio di reportistica.
Ordine di introduzione: prima TLS-RPT, poi MTA-STS su testing, qualche settimana di lettura dei rapporti, e solo dopo enforce. Assomiglia alla linea guida graduale di DMARC: prima osservare, poi diventare rigorosi.
DANE: il certificato nel DNS, protetto con DNSSEC
DANE (DNS-based Authentication of Named Entities) affronta la questione in modo diverso. Lei inserisce nel DNS un record TLSA per ogni server MX, con un'impronta digitale del certificato o della chiave:
_25._tcp.mx1.example.com. 3600 IN TLSA 3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5_25._tcp significa: per SMTP sulla porta 25. I tre numeri indicano come va letto il valore. Per i server di posta, 3 1 1 è il più usato: "questa è l'impronta digitale SHA-256 della chiave pubblica di esattamente questo server". Compare anche 2 1 1: in tal caso contiene l'impronta digitale di un certificato intermedio.
Un mittente che supporta DANE vede il record TLSA, richiede la cifratura e controlla se il certificato del server corrisponde. Se non corrisponde, non consegna.
Perché DANE è sicuro contro risposte DNS falsificate? Perché funziona solo con DNSSEC (corso DNS, lezione 8.1). Senza una catena DNSSEC valida, i record TLSA vengono ignorati. Questa è proprio la soglia d'ingresso: sia il Suo dominio (per l'MX) sia la zona del server di posta devono essere firmati.
DANE non ha la debolezza del "primo contatto" come MTA-STS, ed è molto diffuso in particolare in Europa settentrionale. internet.nl lo verifica. Microsoft supporta DANE per la posta in entrata in Exchange Online. Anche i server MX di internet.nl hanno record TLSA.
Attenzione: se sostituisce il certificato di un server di posta con DANE con una nuova chiave, anche il record TLSA deve cambiare, e deve farlo in anticipo: prima aggiunga il nuovo record, attenda che il TTL sia scaduto, e solo allora metta in uso la nuova chiave. Altrimenti i mittenti con DANE rifiuteranno la Sua posta. Con 3 1 1 questo conta solo se la chiave cambia, non a ogni rinnovo con la stessa chiave.
MTA-STS o DANE?
| MTA-STS | DANE | |
|---|---|---|
| Richiede DNSSEC | No | Sì |
| Dove si trova | Record TXT più file di policy su un sito web | Record TLSA per server MX |
| Protegge la prima connessione | No | Sì |
| Manutenzione | Mantenere sito web e certificato per mta-sts. | Aggiornare TLSA in caso di nuova chiave |
Può usarli entrambi insieme. L'RFC 8461 stabilisce che un mittente che supporta DANE dà la precedenza a DANE se sono presenti record TLSA validi.
Chi se ne occupa?
Questo si configura per la posta in entrata sul Suo dominio. Se la Sua posta è gestita da un'azienda di hosting o da un servizio di posta, dipende da quella parte:
- DANE è possibile solo se il fornitore pubblica record TLSA per i suoi server di posta e il Suo dominio ha DNSSEC. Presso WebOké, ad esempio, può attivare DANE nello stesso punto in cui attiva DNSSEC (vedere l'articolo internet.nl qui sotto); presso altri fornitori funziona in modo simile o è già impostato di default.
- MTA-STS a volte può configurarlo Lei stesso, ma allora
mta-sts.example.comdeve essere un sito web con un certificato valido e deve conoscere i nomi MX del Suo fornitore. - TLS-RPT può sempre impostarlo Lei stesso: è solo un record TXT con un indirizzo per i rapporti.
Per la Sua posta in uscita non deve fare nulla: è il server del Suo fornitore a determinare se rispetta MTA-STS e DANE dei destinatari.
Riepilogo
- Tra i server di posta, TLS è per default opportunistico: cifrato quando possibile, senza controllo rigoroso del certificato. Questo rende possibili downgrade e MX falsi.
- MTA-STS: TXT
_mta-stspiù file di policy suhttps://mta-sts.<dominio>/.well-known/mta-sts.txt; modalitàtestingoenforce. - TLS-RPT: TXT
_smtp._tlscon un indirizzo per i rapporti, per rapporti quotidiani sulla cifratura fallita. - DANE: record TLSA su
_25._tcp.<server-mx>, funziona solo con DNSSEC e protegge anche la prima connessione. - Introducetelo come DMARC: prima i rapporti (TLS-RPT,
testing), poi la rigorosità.
Quiz
Esercizio
Esercizio Z5.4: Verificare MTA-STS, TLS-RPT e DANE. Cerchi per gmail.com il record MTA-STS e il record TLS-RPT, apra il file di policy e indichi la modalità (enforce, testing o none). Cerchi poi per un server MX di internet.nl il record TLSA su _25._tcp.<server-mx> e indichi i primi tre numeri di uno dei record. Facoltativo: le stesse domande per il Suo dominio (lì la risposta può essere "nessuno"). Il programma interroga tutto dal vivo e confronta.
Per approfondire
I passaggi descritti in questi articoli valgono per i pannelli di WebOké; presso altri fornitori il funzionamento è simile.
- Checklist di internet.nl
- Che cos'è il DNSSEC?
- Corso gratuito DNS 8.1: DNSSEC in parole semplici
- internet.nl, verifichi la Sua email (test indipendente di STARTTLS, DANE e altro): https://internet.nl/
- RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE per SMTP)