In sintesi, MTA-STS è un metodo per proteggere ulteriormente le email dall'intercettazione (cioè attacchi Man-in-the-Middle, aka MitM) durante il trasferimento tra i server di posta. Risolve parzialmente problemi architetturali ereditati dai protocolli di posta elettronica ed è descritto in uno standard relativamente recente, RFC 8461. Mail.ru è il primo grande servizio di posta in Runet a implementare questo standard. Maggiori dettagli possono essere trovati di seguito.

Quale problema risolve MTA-STS?

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

Come funziona il meccanismo di consegna delle email da un utente all'altro:

Storicamente, gli attacchi MitM sono stati possibili in tutti i luoghi dove transitano le email.

Lo standard RFC 8314 richiede l'uso obbligatorio di TLS tra il client di posta dell'utente (MUA) e il server di posta. Se il tuo server e le applicazioni di posta utilizzate rispettano RFC 8314, hai (in gran parte) eliminato le possibilità di attacchi Man-in-the-Middle tra l'utente e i server di posta.

Rispettare le buone pratiche comuni (RFC 8314 standardizzate) elimina gli attacchi nei pressi dell'utente:

I server di posta Mail.ru rispettano RFC 8314 ancora prima che lo standard fosse adottato; in effetti, esso semplicemente certifica pratiche già adottate, e non è stato necessario effettuare ulteriori configurazioni. Tuttavia, se il tuo server di posta consente ancora connessioni tramite protocolli non sicuri, è fondamentale implementare le raccomandazioni di questo standard, poiché è probabile che almeno una parte dei tuoi utenti lavori con la posta senza crittografia, anche se tu la supporti.

Il client di posta lavora sempre con lo stesso server di posta della stessa organizzazione. Si può forzare tutti gli utenti a connettersi in modo sicuro, rendendo tecnicamente impossibile la connessione insicura (questo è esattamente ciò che richiede RFC 8314). A volte questo può essere complicato, ma è realizzabile. La situazione con il traffico tra i server di posta è ancora più complessa. I server appartengono a diverse organizzazioni e sono spesso utilizzati in modalità 'installato e dimenticato', rendendo impossibile il passaggio contemporaneo a un protocollo sicuro senza compromettere la connettività. In SMTP esiste già da tempo l'estensione STARTTLS, che consente ai server che supportano la crittografia di passare a TLS. Ma un attaccante, che ha la possibilità di influenzare il traffico, può 'tagliare' le informazioni di supporto di questo comando e costringere i server a comunicare tramite il protocollo di testo normale (cosiddetta attacco di downgrade). Per questo motivo, per STARTTLS di solito non viene controllata la validità del certificato (un certificato non attendibile può proteggere da attacchi passivi, e questo è meglio che inviare un'email in chiaro). Pertanto, STARTTLS protegge solo dalle intercettazioni passive.

MTA-STS affronta 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, l'email sarà inviata solo tramite una connessione TLS, solo a server definiti dalla politica, e solo con verifica del certificato del server.

Perché parzialmente? MTA-STS funziona solo se entrambe le parti si sono impegnate nell'implementazione di questo standard, e MTA-STS non protegge da scenari in cui un attaccante può ottenere un certificato valido per il dominio da uno dei CA pubblici.

Come funziona MTA-STS

Destinatario

Configura il supporto STARTTLS con un certificato valido sul server di posta.
Pubblica la politica MTA-STS tramite HTTPS, utilizzando un dominio speciale mta-sts e un percorso well-known speciale, 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 nel DNS con la versione della politica. Quando la politica cambia, questo record deve essere aggiornato (questo segnala al mittente la necessità di richiedere di nuovo la politica). Ad esempio, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Mittente

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

Quando si invia un'email, viene verificato che:

il server a cui viene inviata l'email sia presente nella politica;
il server accetti email utilizzando TLS (STARTTLS) e abbia un certificato valido.

Vantaggi di MTA-STS

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

Svantaggi di MTA-STS

È necessario monitorare la validità del certificato del server web e di posta, la corrispondenza dei nomi e l'aggiornamento tempestivo. Problemi con il certificato porteranno a un'impossibilità di consegnare la posta.

Dal lato del mittente è richiesto un MTA con supporto per le politiche MTA-STS, attualmente non supportato “out of the box” in MTA.

MTA-STS utilizza un elenco di CA radici fidate.

MTA-STS non protegge dalle attacchi in cui l'attaccante utilizza un certificato valido. Nella maggior parte dei casi, gli attacchi MitM vicino al server implicano la possibilità di emettere un certificato. Tale attacco può essere rilevato grazie alla trasparenza dei certificati. Pertanto, nel complesso, MTA-STS mitiga, ma non elimina completamente la possibilità di intercettare il traffico.

Gli ultimi due punti rendono MTA-STS meno sicuro rispetto allo standard concorrente DANE per SMTP (RFC 7672), ma più tecnicamente affidabile, ovvero per MTA-STS è bassa la probabilità che una email non venga consegnata a causa di problemi tecnici derivanti dall'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 frequentemente a guasti tecnici, se si fa riferimento alla statistica di diversi anni di utilizzo (sebbene la affidabilità di DNSSEC e il suo supporto tecnico mostrino in generale una buona tendenza). Per implementare DANE in SMTP dal lato del destinatario, DNSSEC è obbligatorio per la zona DNS, e per DANE è essenziale un supporto corretto di NSEC/NSEC3, su cui ci sono problemi sistemici in DNSSEC.

Se DNSSEC è configurato in modo errato, possono verificarsi rifiuti di consegna della posta, se il mittente supporta DANE, anche se il destinatario non ne sa nulla. Pertanto, nonostante DANE sia uno standard più vecchio e sicuro, e già supportato da alcuni software server dal lato del mittente, di fatto la sua penetrazione rimane insignificante, molte organizzazioni non sono pronte per implementarlo a causa della necessità di implementare DNSSEC, il che ha notevolmente rallentato l'adozione di DANE in tutti questi anni.

DANE e MTA-STS non confliggono tra loro e possono essere utilizzati insieme.

Cosa sappiamo sul supporto MTA-STS in Mail.ru

Mail.ru pubblica da tempo una politica MTA-STS per tutti i principali domini. Attualmente stiamo implementando la 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 verrà forzato un regime bloccante per una piccola parte del traffico SMTP in uscita, gradualmente fino ad arrivare al 100% del traffico sarà garantito l'applicazione delle politiche.

Chi altro supporta lo standard

Attualmente, le politiche MTA-STS sono pubblicate da circa il 0,05% dei domini attivi, tuttavia, già proteggono una grande quantità 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 l'implementazione dello standard sarà realizzata a breve.

Come influirà su di me?

Nessun impatto, se il tuo dominio non pubblica una politica MTA-STS. Se pubblichi una politica, le email per gli utenti del tuo server di posta saranno meglio protette dall'intercettazione.

Come posso implementare MTA-STS?

Supporto MTA-STS dal lato del destinatario

È sufficiente pubblicare una politica tramite HTTPS e registrazioni DNS, configurare un certificato valido da uno dei CA fidati (può essere Let’s Encrypt) per STARTTLS in MTA (STARTTLS è supportato in tutti gli MTA moderni), non è necessaria alcuna supporto speciale da parte dell'MTA.

Passo dopo passo, appare così:

Configura STARTTLS nel MTA utilizzato (postfix, exim, sendmail, Microsoft Exchange, ecc.).
Assicurati che sia utilizzato un certificato valido (rilasciato da un CA fidato, non scaduto, il soggetto del certificato corrisponde al record MX attraverso il quale viene consegnata la posta per il tuo dominio).
Configura un record TLS-RPT attraverso cui saranno consegnati i rapporti sull'applicazione delle politiche (con servizi che supportano l'invio di rapporti TLS). Ecco un 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@example.com.
Monitora i rapporti per alcuni giorni, assicurati che non ci siano errori.
Pubblica la tua politica MTA-STS tramite HTTPS. La politica viene pubblicata come file di testo con terminatori di riga CRLF nella posizione specificata.
```
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 version specifica la versione della politica (attualmente è STSv1), Mode definisce il regime di applicazione della politica, testing — modalità di test (la politica non viene applicata), enforce — modalità "operativa". Prima pubblica la politica in modalità: testing, se non ci sono problemi con la politica in modalità test, dopo un po' di tempo puoi passare alla modalità: enforce.
In mx viene specificata la lista di tutti i server di posta che possono ricevere email per il tuo dominio (ogni server deve avere configurato un certificato corrispondente 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 ne blocca la restituzione o danneggia i record DNS durante il periodo di caching; è possibile segnalare la necessità di richiedere nuovamente la politica attraverso la modifica del record mta-sts nel DNS).
Pubblica un record TXT nel DNS:
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Nel campo id puoi utilizzare un identificatore arbitrario (ad esempio un timestamp), al cambiamento della politica deve cambiare, questo permette ai mittenti di comprendere che devono richiedere nuovamente la politica memorizzata (se l'identificatore è diverso da quello memorizzato).

Supporto MTA-STS da parte del mittente

Attualmente è scarso, dato che lo standard è fresco.

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 terze parti di cui si parla dettagliatamente su Habr. https://habr.com/en/post/424961/

A proposito di "mandatory TLS"

Recentemente i regolatori stanno prestando attenzione alla sicurezza della posta (e questo è positivo). Ad esempio, DMARC è obbligatorio per tutte le istituzioni governative negli Stati Uniti e viene sempre più richiesto nel settore finanziario. Nelle aree regolate, il livello di adozione dello standard raggiunge il 90%. Attualmente alcuni regolatori richiedono l'implementazione del "mandatory TLS" con domini specifici, ma il meccanismo per garantire il "mandatory TLS" non viene definito e nella pratica questa configurazione è spesso implementata in un modo che non protegge minimamente da attacchi reali, che sono già previsti in meccanismi come DANE o MTA-STS.

Se un regolatore richiede l'implementazione del "mandatory TLS" con domini specifici, ti consigliamo di considerare MTA-STS o il suo analogo parziale come meccanismo più appropriato, poiché elimina la necessità di effettuare configurazioni sicure per ogni dominio singolarmente. Se hai difficoltà con l'implementazione della parte client di MTA-STS (finché il protocollo non riceve un ampio supporto, probabilmente avrai difficoltà), puoi raccomandare il seguente approccio:

Pubblica la politica MTA-STS e/o i record DANE (DANE ha senso aggiungerlo solo se per il tuo dominio è già abilitato DNSSEC, mentre MTA-STS lo è comunque), questo proteggerà il traffico verso di te e ti esenterà 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 configurazioni di trasporto separate per ciascun dominio, che fisseranno il 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 mandatory TLS per un dominio senza fissare il relay e verificare il certificato non è efficace dal punto di vista della sicurezza e non aggiunge nulla ai meccanismi esistenti di STARTTLS.

Fonte: habr.com