In breve, MTA-STS è un modo per proteggere ulteriormente le e-mail dall'intercettazione (ovvero attacchi man-in-the-middle, ovvero MitM) quando vengono trasmesse tra server di posta. Risolve parzialmente i problemi architetturali legacy dei protocolli di posta elettronica ed è descritto nello standard relativamente recente RFC 8461. Mail.ru è il primo importante servizio di posta sulla RuNet a implementare questo standard. Ed è descritto più dettagliatamente sotto il taglio.
Quale problema risolve MTA-STS?
Storicamente, i protocolli di posta elettronica (SMTP, POP3, IMAP) trasmettevano informazioni in chiaro, il che rendeva possibile intercettarle, ad esempio, quando si accedeva a un canale di comunicazione.
Come si presenta il meccanismo per consegnare una lettera da un utente a un altro:
Storicamente un attacco MitM era possibile in tutti i luoghi in cui circola la posta.
RFC 8314 richiede l'uso di TLS tra l'applicazione utente di posta (MUA) e il server di posta. Se il tuo server e le applicazioni di posta che utilizzi sono conformi alla RFC 8314, hai (in gran parte) eliminato la possibilità di attacchi Man-in-the-Middle tra l'utente e i server di posta.
Seguire pratiche generalmente accettate (standardizzate da RFC 8314) elimina l'attacco vicino all'utente:
I server di posta di Mail.ru erano conformi alla RFC 8314 anche prima che lo standard fosse adottato; infatti, cattura semplicemente le pratiche già accettate e non abbiamo dovuto configurare nulla di aggiuntivo. Tuttavia, se il tuo server di posta consente ancora agli utenti di utilizzare protocolli non sicuri, assicurati di implementare le raccomandazioni di questo standard, perché Molto probabilmente, almeno alcuni dei tuoi utenti lavorano con la posta senza crittografia, anche se la supporti.
Il client di posta funziona sempre con lo stesso server di posta della stessa organizzazione. E puoi forzare tutti gli utenti a connettersi in modo sicuro e quindi rendere tecnicamente impossibile la connessione per gli utenti non sicuri (questo è esattamente ciò che richiede RFC 8314). Questo a volte è difficile, ma fattibile. Il traffico tra i server di posta è ancora più complicato. I server appartengono a organizzazioni diverse e vengono spesso utilizzati in modalità “imposta e dimentica”, che rende impossibile passare immediatamente a un protocollo sicuro senza interrompere la connettività. SMTP fornisce da tempo l'estensione STARTTLS, che consente ai server che supportano la crittografia di passare a TLS. Ma un utente malintenzionato che ha la capacità di influenzare il traffico può “tagliare” le informazioni sul supporto di questo comando e costringere i server a comunicare utilizzando un protocollo di testo semplice (il cosiddetto attacco di downgrade). Per lo stesso motivo, STARTTLS di solito non verifica la validità del certificato (un certificato non attendibile può proteggere dagli attacchi passivi e questo non è peggio dell'invio di un messaggio in chiaro). Pertanto, STARTTLS protegge solo dalle intercettazioni passive.
MTA-STS elimina parzialmente il problema dell'intercettazione delle lettere tra i server di posta, quando l'aggressore ha la capacità di influenzare attivamente il traffico. Se il dominio del destinatario pubblica una policy MTA-STS e il server del mittente supporta MTA-STS, invierà l'e-mail solo tramite una connessione TLS, solo ai server definiti dalla policy e solo con la verifica del certificato del server.
Perché parzialmente? MTA-STS funziona solo se entrambe le parti hanno avuto cura di implementare questo standard e MTA-STS non protegge dagli scenari in cui un utente malintenzionato riesce a ottenere un certificato di dominio valido da una delle CA pubbliche.
Come funziona MTA-STS
destinatario
- Configura il supporto STARTTLS con un certificato valido sul server di posta.
- Pubblica la policy MTA-STS tramite HTTPS; per la pubblicazione vengono utilizzati, ad esempio, uno speciale dominio mta-sts e uno speciale percorso noto
https://mta-sts.mail.ru/.well-known/mta-sts.txt. La policy contiene un elenco di server di posta (mx) che hanno il diritto di ricevere posta per questo dominio. - Pubblica uno speciale record TXT _mta-sts nel DNS con la versione della policy. Quando la policy cambia, questa voce deve essere aggiornata (questo segnala al mittente di interrogare nuovamente la policy). Per esempio,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
mittente
Il mittente richiede il record DNS _mta-sts e, se disponibile, effettua una richiesta di policy tramite HTTPS (controllando il certificato). La policy risultante viene memorizzata nella cache (nel caso in cui un utente malintenzionato ne blocchi l'accesso o falsifichi il record DNS).
Quando si invia la posta, viene controllato che:
- il server a cui viene consegnata la posta è nella policy;
- il server accetta la posta utilizzando TLS (STARTTLS) e dispone di un certificato valido.
Vantaggi di MTA-STS
MTA-STS utilizza tecnologie già implementate nella maggior parte delle organizzazioni (SMTP+STARTTLS, HTTPS, DNS). Per l'implementazione da parte del destinatario non è necessario alcun supporto software speciale per lo standard.
Svantaggi di MTA-STS
È necessario monitorare la validità del certificato del server web e di posta, la corrispondenza dei nomi e il tempestivo rinnovo. Problemi con il certificato comporteranno l'impossibilità di consegnare la posta.
Dal lato del mittente, è richiesto un MTA con supporto per le policy MTA-STS; attualmente MTA-STS non è supportato immediatamente nell'MTA.
MTA-STS utilizza un elenco di CA radice attendibili.
MTA-STS non protegge dagli attacchi in cui l'aggressore utilizza un certificato valido. Nella maggior parte dei casi, MitM vicino al server implica la possibilità di emettere un certificato. Un simile attacco può essere rilevato utilizzando Certificate Transparency. Quindi, in generale, MTA-STS mitiga, ma non elimina del tutto, la possibilità di intercettazione del traffico.
Gli ultimi due punti rendono MTA-STS meno sicuro dello standard DANE concorrente per SMTP (RFC 7672), ma più tecnicamente affidabile, cioè per MTA-STS c'è una bassa probabilità che la lettera non venga consegnata a causa di problemi tecnici causati dall'implementazione della norma.
Standard concorrente - DANE
DANE utilizza DNSSEC per pubblicare le informazioni sui certificati e non richiede fiducia nelle autorità di certificazione esterne, il che è molto più sicuro. Ma l'uso di DNSSEC porta molto più spesso a guasti tecnici, sulla base delle statistiche su diversi anni di utilizzo (sebbene in generale vi sia una tendenza positiva nell'affidabilità di DNSSEC e del suo supporto tecnico). Per implementare DANE in SMTP dal lato destinatario è obbligatoria la presenza di DNSSEC per la zona DNS, mentre per DANE è essenziale il supporto corretto di NSEC/NSEC3, con il quale esistono problemi sistemici in DNSSEC.
Se DNSSEC non è configurato correttamente, possono verificarsi errori di consegna della posta se il lato mittente supporta DANE, anche se il lato ricevente non ne sa nulla. Pertanto, nonostante DANE sia uno standard più vecchio e più sicuro e sia già supportato in alcuni software server lato mittente, in realtà la sua penetrazione rimane insignificante, molte organizzazioni non sono pronte ad implementarlo a causa della necessità di implementare DNSSEC, ciò ha rallentato in modo significativo l'implementazione di DANE in tutti questi anni di esistenza dello standard.
DANE e MTA-STS non sono in conflitto tra loro e possono essere utilizzati insieme.
Cosa offre il supporto MTA-STS in Mail.ru Mail?
Mail.ru pubblica da tempo una politica MTA-STS per tutti i principali domini. Attualmente stiamo implementando la parte client dello standard. Al momento in cui scriviamo le policy sono applicate in modalità non bloccante (se la consegna è bloccata da una policy, la lettera verrà consegnata tramite un server “di riserva” senza applicare policy), quindi la modalità di blocco verrà forzata per una piccola parte del traffico SMTP in uscita, gradualmente per il 100% del traffico sarà supportata l'applicazione dei criteri.
Chi altro sostiene lo standard?
Finora le policy MTA-STS pubblicano circa lo 0.05% dei domini attivi, ma proteggono già un grande volume di traffico di posta, perché Lo standard è supportato dai principali attori: Google, Comcast e in parte Verizon (AOL, Yahoo). Molti altri servizi postali hanno annunciato che il supporto per lo standard verrà implementato nel prossimo futuro.
Come mi influenzerà questo?
No, a meno che il tuo dominio non pubblichi una policy MTA-STS. Se pubblichi la policy, le email per gli utenti del tuo server di posta saranno meglio protette dalle intercettazioni.
Come si implementa MTA-STS?
Supporto MTA-STS dal lato destinatario
È sufficiente pubblicare la policy tramite HTTPS e record in DNS, configurare un certificato valido da una delle CA attendibili (è possibile crittografarlo) per STARTTLS nell'MTA (STARTTLS è supportato in tutti gli MTA moderni), nessun supporto speciale da parte L'MTA è obbligatorio.
Passo dopo passo, assomiglia a questo:
- Configura STARTTLS nell'MTA che stai utilizzando (postfix, exim, sendmail, Microsoft Exchange, ecc.).
- Assicurati di utilizzare un certificato valido (emesso da una CA attendibile, non scaduto, l'oggetto del certificato corrisponde al record MX che consegna la posta per il tuo dominio).
- Configurare un record TLS-RPT attraverso il quale verranno consegnati i report dell'applicazione dei criteri (dai servizi che supportano l'invio di report TLS). Voce di esempio (per il dominio example.com):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»Questa voce indica ai mittenti di posta di inviare report statistici sull'utilizzo di TLS in SMTP a
[email protected].Monitora i report per diversi giorni per assicurarti che non vi siano errori.
- Pubblica la policy MTA-STS su HTTPS. La policy viene pubblicata come file di testo con terminatori di riga CRLF in base alla posizione.
https://mta-sts.example.com/.well-known/mta-sts.txtPolitica di esempio:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400Il campo versione contiene la versione della policy (attualmente
STSv1), Modalità imposta la modalità di applicazione della policy, testing — modalità test (la policy non viene applicata), imposizione — modalità “combattimento”. Per prima cosa pubblica la policy con modalità: testing, se non ci sono problemi con la policy in modalità test, dopo un po' puoi passare alla modalità: apply.In mx viene specificato un elenco di tutti i server di posta che possono accettare posta per il tuo dominio (ogni server deve avere un certificato configurato che corrisponda al nome specificato in mx). Max_age specifica il tempo di caching della policy (una volta che la policy ricordata verrà applicata anche se l'attaccante ne blocca la consegna o corrompe i record DNS durante il tempo di caching, è possibile segnalare la necessità di richiedere nuovamente la policy modificando il DNS mta-sts documentazione).
- Pubblica un record TXT nel DNS:
_mta-sts.example.com. TXT “v=STS1; id=someid;”È possibile utilizzare un identificatore arbitrario (ad esempio un timestamp) nel campo id; quando la policy cambia, dovrebbe cambiare, questo consente ai mittenti di capire che devono richiedere nuovamente la policy memorizzata nella cache (se l'identificatore è diverso da quello memorizzato nella cache).
Supporto MTA-STS sul lato mittente
Finora le è andata male, perché... norma fresca.
- Exim: nessun supporto integrato, esiste uno script di terze parti
- Postfix: non esiste un supporto integrato, esiste uno script di terze parti descritto in dettaglio su Habré
In postfazione sul “TLS obbligatorio”
Ultimamente, le autorità di regolamentazione hanno prestato attenzione alla sicurezza della posta elettronica (e questa è una buona cosa). Ad esempio, DMARC è obbligatorio per tutte le agenzie governative negli Stati Uniti ed è sempre più richiesto nel settore finanziario, con una penetrazione dello standard che raggiunge il 90% nelle aree regolamentate. Ora alcuni regolatori richiedono l’implementazione del “mandatory TLS” con i singoli domini, ma il meccanismo per garantire il “mandatory TLS” non è definito e nella pratica questa impostazione è spesso implementata in modo tale da non proteggere nemmeno minimamente da attacchi reali che sono già previsto in meccanismi come DANE o MTA-STS.
Se il regolatore richiede l'implementazione di un "TLS obbligatorio" con domini separati, consigliamo di considerare MTA-STS o il suo analogo parziale come il meccanismo più adatto, eliminando la necessità di effettuare impostazioni sicure per ciascun dominio separatamente. Se riscontri difficoltà nell'implementazione della parte client di MTA-STS (fino a quando il protocollo non avrà ricevuto un supporto diffuso, molto probabilmente lo faranno), possiamo consigliare questo approccio:
- Pubblica una policy MTA-STS e/o record DANE (DANE ha senso solo se DNSSEC è già abilitato per il tuo dominio, e MTA-STS in ogni caso), questo proteggerà il traffico nella tua direzione ed eliminerà la necessità di chiedere ad altri servizi di posta elettronica per configurare TLS obbligatorio per il tuo dominio se il servizio di posta supporta già MTA-STS e/o DANE.
- Per i servizi di posta elettronica di grandi dimensioni, implementare un "analogo" di MTA-STS attraverso impostazioni di trasporto separate per ciascun dominio, che risolverà l'MX utilizzato per l'inoltro della posta e richiederà la verifica obbligatoria di un certificato TLS per esso. Se i domini pubblicano già una policy MTA-STS, probabilmente ciò può essere fatto senza problemi. Di per sé, abilitare il TLS obbligatorio per un dominio senza riparare il relè e verificarne il certificato è inefficace dal punto di vista della sicurezza e non aggiunge nulla ai meccanismi STARTTLS esistenti.
Fonte: habr.com