Guida all'implementazione di MTA-STS e TLS-RPT

Benvenuti nel vostro manuale dettagliato su MTA-STS e TLS-RPT per acquisire conoscenze pratiche sui protocolli e sulle loro funzionalità.

Contattateci Prenota una demo

Tabella dei contenuti

  1. Cos'è Mail Transfer Agent-Strict Transport Security (MTA-STS)?
  2. Come fa MTA-STS a garantire la crittografia dei messaggi in transito?
  3. Scomporre l'anatomia di un attacco MITM
  4. Come fa MTA-STS a garantire la crittografia TLS?
  5. Cos'è il file di politica MTA-STS?
  6. Come pubblicare il file di politica MTA-STS?
  7. Cos'è il record DNS MTA-STS?
  8. Come distribuire MTA-STS?
  9. Quali sono le sfidee sfide affrontate durante l'implementazione manuale di MTA-STS?
  10. Servizi MTA-STS ospitati da PowerDMARC
  11. Cos'è la segnalazione SMTP TLS (TLS-RPT)?
  12. Come abilitare TLS-RPT per il tuo dominio?
  13. Domande frequenti
crittografia tls

Mail Transfer Agent-Strict Transport Security (MTA-STS)

MTA-STS, come suggerisce il nome, è un protocollo che permette il trasporto criptato di messaggi tra due server di posta SMTP. MTA-STS specifica ai server di invio che le e-mail dovrebbero essere inviate solo su una connessione cifrata TLS, e non dovrebbero essere consegnate affatto nel caso in cui una connessione protetta non sia stabilita tramite il comando STARTTLS. Migliorando la sicurezza delle e-mail in transito, MTA-STS aiuta a mitigare gli attacchi Man-In-The-Middle (MITM) come gli attacchi SMTP downgrade e gli attacchi DNS spoofing.

Leggi di più

Come fa MTA-STS a garantire la crittografia dei messaggi in transito?

Facciamo un semplice esempio per capire come i messaggi vengono criptati durante il flusso di e-mail. Se un MTA sta inviando un'email a [email protected]l'MTA esegue una query DNS per scoprire a quale MTA l'email deve essere inviata. La richiesta DNS viene inviata per recuperare i record MX di powerdmarc.com. L'MTA che invia si connette successivamente all'MTA ricevente trovato nel risultato della query DNS, chiedendo se questo server ricevente supporta la crittografia TLS. Se lo fa, l'e-mail viene inviata su una connessione criptata, tuttavia, se non lo fa, l'MTA di invio non riesce a negoziare una connessione protetta e invia l'e-mail in chiaro.

L'invio di email su un percorso non criptato apre la strada ad attacchi di monitoraggio pervasivi come MITM e SMTP downgrade. Scopriamo come:

Scomporre l'anatomia di un attacco MITM

Essenzialmente, un attacco MITM ha luogo quando un attaccante sostituisce o cancella il comando STARTTLS per far tornare la connessione protetta ad una non protetta, senza crittografia TLS. Questo viene definito un attacco di downgrade. Dopo aver eseguito con successo un attacco di downgrade, l'attaccante può accedere e visualizzare il contenuto delle e-mail senza ostacoli.

Un attaccante MITM può anche sostituire i record MX nella risposta della query DNS con un server di posta a cui ha accesso e di cui ha il controllo. L'agente di trasferimento della posta in questo caso consegna l'e-mail al server dell'attaccante, permettendogli di accedere e manomettere il contenuto dell'e-mail. L'e-mail può essere successivamente inoltrata al server del destinatario previsto, senza essere rilevata. Questo è noto come un attacco di spoofing DNS.

Domande frequenti

Il pannello di controllo di PowerDMARC vi permette di impostare automaticamente MTA-STS e TLS-RPT per il vostro dominio pubblicando solo tre record CNAME nel DNS del vostro dominio. Dall'hosting dei file di policy MTAS-STS e dei certificati alla manutenzione del server web, ci occupiamo di tutto in background senza che voi dobbiate apportare alcuna modifica al vostro DNS. Il deployment di MTA-STS da parte vostra con PowerDMARC è ridotto a pochi clic.

Puoi distribuire e gestire MTA-STS per tutti i tuoi domini dal tuo account PowerDMARC, attraverso un unico pannello di vetro. Nel caso in cui qualcuno di quei domini stia usando server di posta ricevente che non supportano STARTTLS, ciò si rifletterà nei tuoi rapporti TLS, a condizione che tu abbia abilitato TLS-RPT per quei domini.

È sempre consigliabile impostare la modalità della politica MTA-STS su test durante le fasi iniziali di implementazione in modo da poter monitorare le attività e ottenere visibilità nel vostro ecosistema di posta elettronica prima di passare a una politica più aggressiva come enforce. In questo modo, anche se le email non vengono inviate su una connessione criptata TLS, verrebbero comunque inviate in chiaro. Tuttavia, assicurati di abilitare TLS-RPT per ricevere una notifica se ciò accade.

TLS-RPT è un ampio meccanismo di segnalazione che ti permette di ricevere una notifica nel caso in cui una connessione protetta non possa essere stabilita e l'e-mail non sia stata consegnata. Questo ti aiuta a rilevare i problemi nella consegna delle e-mail o le e-mail consegnate su una connessione non protetta in modo da poterli mitigare e risolvere prontamente.

Dovete notare che mentre MTA-STS assicura che le e-mail siano trasferite su una connessione cifrata TLS, nel caso in cui una connessione protetta non sia negoziata, l'e-mail potrebbe non essere consegnata affatto. Questo però è necessario perché assicura che le e-mail non vengano consegnate su un percorso non crittografato. Per evitare tali problemi, è consigliabile impostare una policy MTA-STS su una modalità di test e abilitare TLS-RPT per il tuo dominio inizialmente, prima di procedere alla modalità MTA-STS enforce. 

Potete facilmente cambiare la vostra modalità MTA-STS dalla dashboard di PowerMTA-STS selezionando la modalità di policy desiderata e salvando le modifiche senza il bisogno di fare alcun cambiamento al vostro DNS.

Potete disattivare MTA-STS per il vostro dominio impostando la modalità di policy su none, specificando così agli MTA che il vostro dominio non supporta il protocollo, o cancellando il vostro record TXT DNS MTA-STS. 

I record MX per il file di policy MTA-STS dovrebbero includere le voci per tutti i server di posta ricevente utilizzati dal vostro dominio.