Pubblicare MTA-STS e TLS-RPT prima in modalità testing

SPF, DKIM e DMARC impediscono ad altri di falsificare il Suo nome (può verificare il Suo record DMARC), ma nessuno di essi impedisce a un server mittente di consegnarLe la posta in chiaro. MTA-STS Le permette di pubblicare una policy che dichiara che i Suoi server di posta supportano TLS autenticato, mentre TLS-RPT Le segnala quando i mittenti non sono riusciti a ottenerlo. Può distribuire entrambi con due record DNS e un file di testo, e può partire da una modalità pensata per un'adozione graduale.

Cosa lascia scoperto STARTTLS

La cifratura della posta tra server usa l'estensione STARTTLS ed è opportunistica. RFC 8461 descrive il punto debole: un attaccante in grado di eliminare la risposta "250 STARTTLS" dalla sessione SMTP, oppure di reindirizzarla sovrascrivendo il record MX risolto, può forzare un downgrade o intercettare la sessione.

DANE è l'altra soluzione, definita in RFC 7672, ma richiede DNSSEC. MTA-STS si affida invece alle certification authority e non richiede DNSSEC, «a costo di rischiare downgrade malevoli» secondo le parole stesse dell'RFC. Se utilizza già DANE, i due meccanismi non entrano in conflitto: i mittenti che implementano MTA-STS non devono permettere che esso scavalchi una validazione DANE fallita.

Le linee guida dell'NCSC sulla sicurezza della posta elettronica affermano che il Suo servizio dovrebbe essere in grado di inviare e ricevere email tramite TLS e che dovrebbe proteggere tutti i Suoi domini, compresi quelli ospitati presso provider cloud come Google G Suite e Microsoft O365.

Primo passo: la policy, in modalità testing

MTA-STS si compone di due parti. Un record TXT in _mta-sts.example.com annuncia che esiste una policy e ne indica la versione:

_mta-sts.example.com. IN TXT "v=STSv1; id=20250101000000Z;"

L'id è formato da lettere e cifre, fino a 32 caratteri, e deve identificare in modo univoco questa versione della policy. Non esiste alcun ordinamento implicito, quindi usare un timestamp è un'abitudine e non un obbligo. Pubblichi esattamente un record di questo tipo: i mittenti scartano i record che non iniziano con v=STSv1; e, se dopo lo scarto il numero di record non è uno, presumono che Lei non abbia alcuna policy.

La policy vera e propria viene scaricata via HTTPS da un indirizzo fisso, costruito anteponendo mta-sts al Suo dominio:

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

La serva come text/plain, perché ai mittenti viene richiesto di controllare il media type. Il file ha questo aspetto:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.net
max_age: 604800

Ogni riga mx: è una voce a sé stante, con un hostname completo oppure un suffisso con wildcard come *.example.net. Elenchi ogni host presente nei Suoi record MX attivi, compreso quello di un eventuale provider cloud.

Le tre modalità sono enforce, testing e none. L'RFC descrive testing come una modalità facoltativa che consente adozioni graduali per rilevare i malfunzionamenti della policy, ed è per questo che conviene iniziare da lì.

Il valore max_age è espresso in secondi, fino a 31557600, e 604800 (una settimana) è l'esempio fornito dall'RFC stessa. L'RFC prevede per la produzione valori tipicamente nell'ordine di settimane o più. Il mio consiglio: durante i test lo mantenga a una settimana o meno, in modo che una policy corretta raggiunga rapidamente i mittenti, e lo aumenti quando enforce si sarà dimostrato stabile.

Secondo passo: attivare TLS-RPT

Il rilevamento funziona solo se i mittenti Le comunicano ciò che hanno osservato. Pubblichi un record TXT in _smtp._tls.example.com:

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

Il campo rua può anche essere un URI https: in tal caso i mittenti inviano il report con una POST, ed è ammesso un elenco separato da virgole. Come per il record MTA-STS, esattamente un record TXT deve iniziare con v=TLSRPTv1;, altrimenti i mittenti presumono che Lei non implementi il protocollo.

Se sceglie mailto, utilizzi una casella dedicata. I mittenti consegnano questi report anche quando TLS fallisce, quindi un report potrebbe arrivare non cifrato. I report inviati via email devono riportare una firma DKIM valida del dominio che li emette, e l'RFC stabilisce che i destinatari devono ignorare quelli privi di firma. Scarti i report non firmati invece di agire sulla base di essi.

Verificare ciò che vedono i mittenti

Interroghi entrambi i record e scarichi il file della policy dall'esterno della Sua rete:

dig TXT _mta-sts.example.com
dig TXT _smtp._tls.example.com
curl -si https://mta-sts.example.com/.well-known/mta-sts.txt

L'output di dig dovrebbe mostrare un solo record per ciascuna query, con il prefisso v= all'inizio. L'output di curl dovrebbe mostrare un 200, Content-Type: text/plain e il corpo della policy: controlli quindi che mode e ogni riga mx: corrispondano a quanto desiderato. Corregga qualsiasi errore di certificato segnalato da curl prima di pubblicare il record TXT.

Leggere i report

I report sono file JSON che coprono un intervallo di tempo, con un riepilogo delle consegne in termini di successi e fallimenti. L'RFC raggruppa i fallimenti in negoziazione, policy, generali e transitori. I report possono arrivare compressi (l'RFC definisce application/tlsrpt+gzip), quindi li decomprima prima di leggerli:

gzip -dc report.json.gz | jq .

I nomi dei campi sono definiti nella sezione 4.4 di RFC 8460. Legga prima i conteggi del riepilogo, poi le voci relative ai fallimenti.

Un report con molti successi e nessun fallimento è ciò che si vuole vedere. L'RFC osserva che un report può fungere da heartbeat, mostrando che TLS viene negoziato come previsto, e una serie costante di report puliti è la Sua prova per procedere. I fallimenti che indicano uno dei Suoi host MX rimandano a un certificato o a un pattern mx da correggere. Un mittente con uno stack difettoso è un problema suo.

Un aumento dei fallimenti STARTTLS che non riesce a ricondurre a una modifica deve essere segnalato a chi gestisce gli incidenti o, se non dispone di nessuno, al nostro team di incident response.

Passare a enforce

Attenda che i report siano puliti lungo tutti i Suoi normali flussi di posta, compresi i mittenti poco frequenti come i sistemi di fatturazione mensile. Poi modifichi mode: testing in mode: enforce e cambi l'id nel record TXT, perché i mittenti lo confrontano con la copia in cache per capire che qualcosa è cambiato.

I mittenti possono conservare una policy in cache fino a max_age dall'ultimo recupero, quindi un errore può persistere. Anche eliminare il record TXT non rimuove una policy in cache, come sottolinea l'RFC. La sezione 8.3 di RFC 8461 tratta la rimozione e Le conviene leggerla prima di averne bisogno.

Da dove iniziare

1. Elenchi i Suoi host MX attivi, compreso quello di un eventuale provider cloud, e verifichi che ciascuno presenti un certificato valido corrispondente al proprio nome.
2. Configuri l'host mta-sts su HTTPS e serva il file della policy come text/plain con mode: testing.
3. Pubblichi l'unico record TXT _mta-sts con un id nuovo, poi esegua i controlli dig e curl descritti sopra.
4. Pubblichi il record TXT _smtp._tls che punta a una casella dedicata o a un endpoint HTTPS, e verifichi la Sua configurazione complessiva con il nostro verificatore di sicurezza email.
5. Esamini i report per almeno un ciclo operativo completo, comprese le elaborazioni di fine mese (per la maggior parte delle organizzazioni, un mese). Corregga ogni fallimento di Sua competenza, poi passi a enforce e cambi l'id.