In breve, MTA-STS è un modo per proteggere ulteriormente le email da intercettazioni (cioè attacchi man-in-the-middle aka MitM) durante il trasferimento tra i server di posta. Risolve parzialmente i problemi architettonici ereditati dai protocolli di posta elettronica ed è descritto in uno standard relativamente recente, il RFC 8461. La posta Mail.ru è il primo grande servizio di posta nel Runet ad implementare questo standard. Dettagli ulteriori vengono forniti nel seguito.

Quale problema risolve MTA-STS?

Storicamente, i protocolli di posta elettronica (SMTP, POP3, IMAP) trasmettevano informazioni in chiaro, il che consente di intercettarle, ad esempio, durante l'accesso al canale di comunicazione.

Come avviene la consegna di una email da un utente all'altro:

Storicamente, l'attacco MitM è stato possibile in tutti i punti in cui viaggia la posta.

Lo standard RFC 8314 richiede l'uso obbligatorio di TLS tra il programma di posta dell'utente (MUA) e il server di posta. Se il tuo server e le applicazioni di posta in uso rispettano il RFC 8314, hai (in larga misura) eliminato la possibilità di attacchi Man-in-the-Middle tra gli utenti e i server di posta.

Il rispetto delle pratiche condivise (standardizzate nel RFC 8314) elimina l'attacco vicino all'utente:

I server di posta Mail.ru rispettavano il RFC 8314 anche prima dell'adozione dello standard; infatti, esso fissa semplicemente pratiche già in uso, e non è stato necessario alcun ulteriore intervento. Tuttavia, se il tuo server di posta consente ancora agli utenti di utilizzare protocolli non sicuri, assicurati di implementare le raccomandazioni di questo standard, poiché è probabile che parte dei tuoi utenti utilizzi la posta senza crittografia, anche se tu la supporti.

Il client di posta lavora sempre con lo stesso server di posta della stessa organizzazione. È possibile forzare tutti gli utenti a connettersi in modo sicuro, rendendo poi impossibile la connessione non sicura (questo è ciò che richiede precisamente il RFC 8314). A volte è complicato, ma attuabile. La situazione è ancora più complessa con il traffico tra server di posta. I server appartengono a diverse organizzazioni e spesso vengono utilizzati in modalità 'installato e dimenticato', rendendo impossibile un passaggio immediato a un protocollo sicuro senza compromettere la connettività. In SMTP è già da tempo previsto l'ampliamento STARTTLS, che consente ai server che supportano la crittografia di passare a TLS. Tuttavia, un attaccante che può influenzare il traffico può 'cancellare' le informazioni relative al supporto di questo comando e costringere i server a comunicare tramite il protocollo di testo normale (il cosiddetto downgrade attack). Per lo stesso motivo, per STARTTLS di solito non viene verificata la corrispondenza del certificato (un certificato non attendibile può proteggere da attacchi passivi, e questo non è peggio dell'invio di un messaggio in chiaro). Pertanto, STARTTLS protegge solo da intercettazioni passive.

MTA-STS elimina parzialmente il problema dell'intercettazione delle email tra server di posta, quando l'attaccante ha la possibilità di influenzare attivamente il traffico. Se il dominio del destinatario pubblica una politica MTA-STS e il server del mittente supporta MTA-STS, invierà la mail solo attraverso una connessione TLS, solo ai server definiti nella politica e solo con verifica del certificato del server.

Perché parzialmente? MTA-STS funziona solo se entrambe le parti si sono occupate di implementare questo standard, e MTA-STS non protegge da scenari in cui l'attaccante ha la possibilità di ottenere un certificato valido per il dominio in uno dei CA pubblici.

Come funziona MTA-STS

Destinatario

Configura il supporto STARTTLS con un certificato valido sul server di posta.
Pubblica tramite HTTPS la politica MTA-STS, utilizzando un dominio speciale mta-sts e un percorso well-known specifico, ad esempio https://mta-sts.mail.ru/.well-known/mta-sts.txt. La politica contiene un elenco di server di posta (mx) autorizzati a ricevere email per questo dominio.
Pubblica un record TXT speciale _mta-sts in DNS con la versione della politica. Quando la politica viene modificata, questo record deve essere aggiornato (questo segnala al mittente di dover richiedere nuovamente la politica). Ad esempio, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Mittente

Il mittente richiede il record DNS _mta-sts, se presente, effettua una richiesta per la politica tramite HTTPS (verificando il certificato). La politica ricevuta viene memorizzata nella cache (nel caso in cui un attaccante blocchi l'accesso ad essa o sostituisca il record DNS).

Quando si invia posta, viene verificato che:

il server a cui viene consegnata la posta sia nella politica;
il server accetti la posta utilizzando TLS (STARTTLS) e disponga di un certificato valido.

Vantaggi di MTA-STS

MTA-STS utilizza tecnologie già implementate nella maggior parte delle organizzazioni (SMTP+STARTTLS, HTTPS, DNS). Non è necessaria alcuna supporto software speciale per l'implementazione da parte del destinatario.

Svantaggi di MTA-STS

È necessario monitorare la validità del certificato del server web e della posta, la corrispondenza dei nomi e gli aggiornamenti tempestivi. Problemi con il certificato porteranno all'impossibilità di consegnare la posta.

Dallato del mittente è richiesta un MTA con supporto per le politiche MTA-STS; attualmente, MTA-STS non è supportato "out of the box" in MTA.

MTA-STS utilizza un elenco di CA radicati fidati.

MTA-STS non protegge da attacchi in cui un attaccante utilizza un certificato valido. Nella maggior parte dei casi, una MitM vicino al server implica la possibilità di emettere certificati. Tale attacco può essere rilevato attraverso Certificate Transparency. Pertanto, in generale, MTA-STS mitiga, ma non elimina completamente la possibilità di intercettazione del traffico.

Gli ultimi due punti rendono MTA-STS meno sicuro rispetto allo standard concorrente DANE per SMTP (RFC 7672), ma più tecnicamente affidabile; cioè, per MTA-STS c'è bassa probabilità che un'email non venga consegnata a causa di problemi tecnici legati all'implementazione dello standard.

Standard concorrente — DANE

DANE utilizza DNSSEC per pubblicare informazioni sui certificati e non richiede fiducia nei certificatori esterni, il che è molto più sicuro. Tuttavia, l'uso di DNSSEC porta a fallimenti tecnici molto più frequentemente, se ci si basa sulle statistiche di diversi anni di utilizzo (anche se si osserva una tendenza positiva nell'affidabilità di DNSSEC e nel suo supporto tecnico complessivo). Per implementare DANE in SMTP dal lato del destinatario, è obbligatorio avere DNSSEC per la zona DNS, e per DANE è fondamentale il corretto supporto NSEC/NSEC3, su cui ci sono problemi sistematici in DNSSEC.

Se DNSSEC è configurato in modo errato, ciò può portare a fallimenti nella consegna delle email, se il mittente supporta DANE, anche se il destinatario non è a conoscenza di esso. Pertanto, nonostante DANE sia uno standard più vecchio e sicuro già supportato in alcuni software server dal lato del mittente, la sua penetrazione rimane in realtà insignificante, molte organizzazioni non sono pronte ad adottarlo a causa della necessità di implementare DNSSEC, il che ha notevolmente ritardato l'adozione di DANE in tutti questi anni di esistenza dello standard.

DANE e MTA-STS non sono in conflitto e possono essere utilizzati insieme.

Qual è il supporto per MTA-STS in Mail.ru

Mail.ru pubblica già da tempo la politica MTA-STS per tutti i principali domini. Attualmente stiamo lavorando all'implementazione della parte client dello standard. Al momento della scrittura dell'articolo, le politiche sono applicate in modalità non bloccante (nel caso in cui la consegna sia bloccata dalla politica, l'email sarà consegnata attraverso un server 'di riserva' senza applicare le politiche), in seguito sarà forzata la modalità bloccante per una piccola parte del traffico SMTP in uscita, gradualmente il 100% del traffico supporterà l'applicazione delle politiche.

Chi altro supporta lo standard

Attualmente le politiche MTA-STS sono pubblicate da circa lo 0,05% dei domini attivi, ma, nonostante ciò, già proteggono un grande volume di traffico email, poiché lo standard è supportato da grandi attori come Google, Comcast e parzialmente Verizon (AOL, Yahoo). Molti altri servizi di posta hanno dichiarato che il supporto per lo standard sarà implementato nel prossimo futuro.

Come mi influenzerà?

Nessuna, se il tuo dominio non pubblica una politica MTA-STS. Se pubblichi la politica, le email degli utenti del tuo server di posta saranno meglio protette da intercettazioni.

Come posso implementare MTA-STS?

Supporto MTA-STS sul lato del destinatario

È sufficiente pubblicare la politica tramite HTTPS e registrazioni DNS, configurare un certificato valido da una delle CA fidate (puoi usare Let's Encrypt) per STARTTLS in MTA (STARTTLS è supportato da tutti i moderni MTA), non è richiesta alcuna supporto speciale da parte dell'MTA.

In sintesi, appare così:

Configura STARTTLS nel MTA utilizzato (postfix, exim, sendmail, Microsoft Exchange, ecc.).
Assicurati che venga utilizzato un certificato valido (rilasciato da una CA fidata, non scaduto, il soggetto del certificato corrisponde al record MX attraverso il quale viene recapitata la posta per il tuo dominio).
Configura il record TLS-RPT, dove verranno inviati i rapporti sull'applicazione delle politiche (da parte dei servizi che supportano l'invio di rapporti TLS). Esempio di record (per il dominio example.com):
```
smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"
```
Questo record istruisce i mittenti di posta a inviare rapporti statistici sull'uso di TLS in SMTP all'indirizzo tlsrpt@exmple.com.
Monitora i rapporti per alcuni giorni, assicurati che non ci siano errori.
Pubblica la politica MTA-STS tramite HTTPS. La politica è pubblicata come file di testo con terminatori di riga CRLF nella posizione.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Esempio di politica:
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Il campo versione contiene la versione della politica (attualmente è STSv1), Mode definisce il modo di applicazione della politica, testing — modalità di testing (politica non applicata), enforce — modalità 'operativa'. Pubblica prima la politica con mode: testing, se non ci sono problemi con la politica in modalità di testing, dopo un certo tempo puoi passare a mode: enforce.
In mx viene specificata la lista di tutti i server di posta che possono ricevere posta per il tuo dominio (ogni server deve avere configurato un certificato che corrisponda al nome specificato in mx). Max_age definisce il tempo di caching della politica (una volta memorizzata, la politica verrà applicata anche se un attaccante blocca la sua restituzione o altera i record DNS durante il tempo di caching, segnalare la necessità di richiedere nuovamente la politica può avvenire tramite modifica del record mta-sts DNS).
Pubblica una registrazione DNS TXT:
```
_mta-sts.example.com. TXT "v=STS1; id=someid;"
```
Nel campo id è possibile utilizzare un identificatore arbitrario (ad esempio un timestamp), che deve cambiare al variare della politica; questo consente ai mittenti di comprendere che è necessario richiedere nuovamente la politica memorizzata nella cache (se l'identificatore è diverso da quello memorizzato).

Supporto MTA-STS da parte del mittente

Al momento è in fase iniziale, poiché lo standard è nuovo.

Exim — non ha supporto integrato, esiste uno script di terze parti https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix — non ha supporto integrato, esiste uno script di cui si parla in dettaglio su Habr https://habr.com/en/post/424961/

Come postfazione su «mandatory TLS»

Negli ultimi tempi i regolatori prestano attenzione alla sicurezza delle email (e questo è positivo). Ad esempio, DMARC è obbligatorio per tutte le istituzioni statali negli Stati Uniti e viene richiesto sempre più frequentemente nel settore finanziario; nei settori regolamentati la diffusione di questo standard raggiunge il 90%. Attualmente alcuni regolatori richiedono l'implementazione di «mandatory TLS» con domini specifici, ma il meccanismo per garantire il «mandatory TLS» non è definito e, nella pratica, questa impostazione viene spesso implementata in un modo che non protegge minimamente da attacchi reali, già previsti in meccanismi come DANE o MTA-STS.

Se un regolatore richiede l'implementazione di «mandatory TLS» con domini specifici, raccomandiamo di considerare MTA-STS o un suo analogo parziale come meccanismo più adatto; elimina la necessità di effettuare impostazioni sicure per ogni singolo dominio. Se hai difficoltà con l'implementazione della parte client di MTA-STS (fino a quando il protocollo non avrà ricevuto un ampio supporto, probabilmente ci saranno), si può raccomandare questo approccio:

Pubblica la politica MTA-STS e/o i record DANE (DANE ha senso aggiungerlo solo se il tuo dominio ha già attivato DNSSEC, mentre MTA-STS deve esserci comunque); questo proteggerà il traffico verso di te e ti esonererà dalla necessità di chiedere ad altri servizi di posta di configurare il mandatory TLS per il tuo dominio, se il servizio di posta supporta già MTA-STS e/o DANE.
Per i grandi servizi di posta, implementa un "analogo" di MTA-STS tramite impostazioni di trasporto separate per ciascun dominio, che fissino l’MX utilizzato per il relay della posta e richiederanno la verifica obbligatoria del certificato TLS. Se i domini pubblicano già una politica MTA-STS, è probabile che questo possa essere fatto senza problemi. L’attivazione del TLS obbligatorio per un dominio senza una fissazione del relay e la verifica del certificato non è efficiente dal punto di vista della sicurezza e non aggiunge nulla ai meccanismi esistenti di STARTTLS.

Fonte: habr.com