Cos'è la segnalazione SMTP TLS (TLS-RPT)?

Poiché le organizzazioni si affidano sempre di più alla posta elettronica come mezzo di comunicazione principale, l'importanza di proteggere questi canali da potenziali minacce non può essere sopravvalutata. Il Transport Layer Security(TLS) garantisce la riservatezza e l'integrità dei dati trasmessi attraverso le reti. 

SMTP TLS Reporting (TLS-RPT) è un protocollo fondamentale che lavora a fianco di MTA-STS per garantire la consegna sicura delle e-mail. Fornendo un feedback dettagliato sui problemi di consegna delle e-mail, TLS-RPT aiuta i proprietari di domini a mantenere l'integrità e la riservatezza delle loro comunicazioni. In questa guida completa, analizzeremo cos'è l'SMTP TLS Reporting, come funziona e perché è essenziale per la vostra strategia di sicurezza delle e-mail".

Diversi protocolli aiutano a crittografare i canali dei messaggi SMTP per impedire ai cyber-attaccanti di intercettare le comunicazioni e-mail. Tra questi, STARTTLS, DANE e MTA-STS. Tuttavia, quando i tentativi di crittografia falliscono durante l'uso di questi protocolli, l'e-mail potrebbe non essere consegnata. TLS-RPT (come descritto in RFC 8460) fornisce un meccanismo di feedback per segnalare questi fallimenti di consegna.

Si consiglia vivamente di utilizzare TLS-RPT insieme a MTA-STS MTA-STS. Vediamo come questi protocolli lavorano insieme per rafforzare la la sicurezza delle e-mail.

Cos'è TLS-RPT?

TLS-RPT (Transport Layer Security Reporting) è uno standard per segnalare i problemi di consegna delle e-mail quando queste non sono crittografate con TLS. La sua importanza nell'autenticazione delle e-mail va di pari passo con la ragione per cui è necessario abilitare la crittografia TLS per le e-mail. 

La crittografia TLS garantisce che ogni e-mail inviata venga consegnata in modo sicuro. Se la connessione non è sicura, molte volte le e-mail non vengono consegnate. TLS-RPT consente ai proprietari di domini di monitorare la consegna delle e-mail e i fallimenti della connessione. I rapporti possono contenere informazioni su: 

• Problemi di gestione dei criteri MTA-STS 
• Motivo e tipo di errore di consegna
• Indirizzo IP degli agenti di trasferimento della posta elettronica che inviano e ricevono le email
• Conteggio totale delle sessioni di connessione TLS riuscite e non riuscite 

In questo modo si ottiene visibilità sui canali di posta elettronica e la possibilità di contrastare più rapidamente i problemi di deliverability.

Semplificate la reportistica SMTP TLS con PowerDMARC!

Come funziona il reporting TLS?

Nella comunicazione e-mail SMTP, la crittografia TLS è "opportunistica". Ciò significa che se non è possibile negoziare un canale crittografato, l'e-mail viene comunque inviata in formato non crittografato (testo normale). In realtà, quasi 4 decenni fa, i protocolli di posta elettronica SMTP non supportavano la crittografia TLS. È stato necessario aggiungerla in un secondo momento sotto forma di comando STARTTLS. 

Il comando STARTTLS viene emesso nelle comunicazioni SMTP solo se entrambe le parti supportano la crittografia TLS. In caso contrario, l'e-mail verrà comunque inviata in chiaro. 

Per sbarazzarsi della crittografia opportunistica in SMTP, è stato introdotto l'MTA-STS (RFC 8461). Il protocollo MTA-STS assicura che le e-mail siano crittografate prima di essere consegnate. Il server di posta elettronica o il Mail Transfer Agent (MTA) negozia con il server ricevente per verificare se supporta il comando STARTTLS. In caso affermativo, l'e-mail viene crittografata con TLS e consegnata. In caso contrario, la consegna fallisce.

Spiegazione passo per passo del funzionamento di TLS-RPT

1. Comprendere il processo di handshake TLS

L'handshake di Transport Layer Security (handshake TLS) è il processo di creazione di una connessione sicura tra due MTA (Mail Transfer Agent) comunicanti. Questo processo prevede le seguenti fasi: 

• L'MTA che invia la posta elettronica invia un messaggio "Client Hello" all'MTA ricevente. Questo messaggio contiene parametri utili come le versioni TLS e le suite di cifratura. 
• L'MTA che riceve la posta elettronica riceve questo messaggio e risponde con un messaggio "Server Hello". Questo contiene la versione TLS e la suite di cifratura selezionate. 
• Dopo l'avvio dell'handshake TLS, l'MTA ricevente invia il proprio certificato SSL/TLS, emesso da una CA (Certificate Authority) affidabile. Questo certificato contiene la chiave pubblica.
• Entrambi gli MTA comunicanti si scambiano in modo sicuro le loro chiavi crittografiche e stabiliscono una connessione crittografata TLS. Ciò garantisce una comunicazione e-mail sicura tra le due parti. 

2. Scenari di handshake TLS non riuscito 

Gli handshake TLS possono fallire per una serie di motivi: 

• Errori di certificazione: I certificati scaduti o quelli emessi da autorità di certificazione non affidabili possono causare errori di handshake TLS.
• Disadattamento delle versioni: Se c'è una mancata corrispondenza tra le versioni di TLS supportate dagli MTA di invio e di ricezione, può verificarsi un fallimento dell'handshake.
• Fallimenti di STARTTLS: Se il comando STARTTLS non è implementato correttamente, può causare un errore di crittografia TLS.
• Applicazione di MTA-STS: Se il destinatario dell'e-mail ha impostato la modalità MTA-STS su "enforce", un handshake TLS non riuscito può portare al rifiuto del messaggio.

3. Generazione e consegna dei rapporti

Quando si verificano errori di crittografia TLS, il server di invio genera un rapporto TLS-RPT e lo invia al proprietario del dominio per un'ulteriore valutazione e risoluzione dei problemi. 

Contenuto del rapporto

Dettagli del server di invio: Indirizzo IP e nome di dominio del mittente.

Dettagli del server di ricezione: Il dominio del destinatario e le informazioni sul server di posta elettronica.

Descrizione dell'errore: Tipo e dettagli dell'errore (ad esempio, errore di certificato, errore di protocollo).

Il tempo del fallimento: Ora in cui si è verificato il problema.

Modalità criterio: Se il dominio è in modalità "testing" o "enforce".

Consegna del rapporto

Questi rapporti TLS vengono inviati in formato JSON all'indirizzo e-mail specificato nel record TXT del DNS TLS-RPT del proprietario del dominio. 

Ruolo della crittografia opportunistica in SMTP

L'SMTP utilizza tradizionalmente una crittografia opportunistica. Ciò significa che tenta di utilizzare TLS, ma ricorre alla consegna non criptata se l'MTA ricevente non supporta TLS.

Tuttavia, la crittografia opportunistica presenta una limitazione importante. In questo tipo di crittografia, che non stabilisce alcun mandato, le e-mail possono essere inviate in chiaro o in plaintext (in un formato non crittografato) se la crittografia TLS fallisce. Tali messaggi non crittografati sono vulnerabili all'intercettazione.

Come funzionano insieme MTA-STS e TLS-RPT

Mail Transfer Agent Strict Transport Security (MTA-STS) e TLS-RPT sono protocolli complementari nell'ecosistema di autenticazione delle e-mail. MTA-STS garantisce che l'MTA di invio debba utilizzare TLS per la consegna e rifiutare le e-mail se la crittografia fallisce,

TLS-RPT consente ai proprietari di domini di monitorare gli handshake TLS non riusciti e di risolvere i problemi. Se implementati insieme, possono prevenire le intercettazioni dei messaggi in transito e ridurre al minimo i problemi di consegna delle e-mail. 

Relazione tra DANE e TLS-RPT

DNS-based Authentication of Named Entities (DANE) è un protocollo che consente ai proprietari di domini di specificare certificati TLS verificati tramite DNSSEC per prevenire gli attacchi man-in-the-middle. Mentre TLS-RPT monitora i guasti TLS, DANE assicura che vengano utilizzati solo certificati affidabili. In questo modo, DANE impedisce attivamente agli aggressori di eseguire attacchi di downgrade TLS e di spoofing dei certificati, mantenendo così l'integrità delle comunicazioni e-mail. 

Perché avete bisogno della segnalazione SMTP TLS?

I proprietari di domini hanno bisogno di essere informati sui problemi di consegna delle e-mail dovuti a errori nella crittografia TLS per le e-mail inviate da un dominio abilitato all'MTA-STS. Il reporting TLS lo rende possibile fornendo queste informazioni. 

• Sicurezza delle e-mail: Evidenziare i rischi della comunicazione via e-mail non criptata (ad esempio, intercettazione, attacchi man-in-the-middle).
• Conformità: Indicare come TLS-RPT aiuta le organizzazioni a soddisfare i requisiti normativi per la protezione dei dati.
• Consegnabilità: Spiegare come TLS-RPT migliora la deliverability delle e-mail identificando e risolvendo i problemi di crittografia.

Passi per l'impostazione di TLS-RPT

È possibile abilitare la segnalazione TLS per il proprio dominio creando un record TXT per TLS-RPT e pubblicandolo nel DNS. Questo record deve essere pubblicato sul sottodominio smtp.tls.yourdomain.com

Passo 1: Generare un record TLS-RPT (utilizzando un generatore di record TLS-RPT)

È possibile registrarsi su PowerDMARC gratuitamente e utilizzare il nostro generatore di record TLS-RPT per creare il vostro record.

Fase 2: Inserire l'indirizzo e-mail di segnalazione

Inserire un indirizzo e-mail sul quale si desidera ricevere i rapporti SMTP TLS.

Fase 3: Pubblicare il record TLS sul proprio DNS

Potete contattare il vostro registrar di dominio per creare un nuovo record TXT per TLS-RPT. Se si gestisce il proprio DNS, modificare le impostazioni DNS per includere il record.

Sintassi ed esempio di record TLS-RPT

Sintassi: v=TLSRPTv1; rua=mailto:[email protected];

Analizziamo i 2 componenti del record di segnalazione TLS fornito:

1. v=TLSRPTv1: Questo tag specifica la versione del protocollo TLS-RPT utilizzata. In questo caso, "TLSRPTv1" indica la prima versione del protocollo.
2. rua=mailto:[email protected]: rua sta per "Reporting URI(s) for Aggregate Data". Questo tag specifica dove il server di posta del destinatario deve inviare i rapporti TLS aggregati.

È possibile configurare più di una destinazione per la ricezione dei rapporti. Per più destinazioni, separare ogni voce con una virgola (,). Si può usare "mailto:" per specificare un indirizzo e-mail per questo passaggio, oppure istruire l'MTA a inviare i rapporti via POST a URL endpoint usando "https:" nel campo rua=. Se si usa "https:" , assicurarsi che il campo definisca l'URL di un server web abilitato HTTPS con un certificato valido. Sia "mailto:" che "https:" possono essere utilizzati anche in un singolo record, separati da una virgola. 

Esempio: v=TLSRPTv1; rua=mailto:[email protected],https://tlsreport.example.com;

Nota: In pratica, si sostituisce "tuodominio.com" con il nome del dominio effettivo in cui si desidera ricevere i rapporti.

Comprendere i rapporti TLS-RPT JSON

Struttura di un rapporto TLS-RPT JSON

I rapporti TLS vengono inviati in formato JSON. Di seguito è riportato un esempio di come potrebbe apparire un rapporto TLS JSON:

{

  "Nome dell'organizzazione": "Organizzazione Inc,

  “date-range”: {

    "start-datetime": “2020-10-22T00:00:00Z”,

    "end-datetime": “2020-10-22T23:59:59Z”

  },

  "contact-info": "[email protected]",

  "report-id": “2020-10-22T00:00:00Z_domain.com”,

  "politiche": [

    {

      “policy”: {

        "tipo di politica": "sts",

        "policy-string": [

          "versione: STSv1",

          "modalità: test",

          "mx: mx.domain.com",

          "mx: mx2.domain.com",

          "mx: mx3.domain.com",

          "max_age: 604800"

        ],

        "policy-domain": "dominio.com"

      },

      “summary”: {

        "numero totale di sessioni riuscite": 15,

        "numero totale di sessioni fallite": 0

      }

Campi chiave e loro significato

Ecco la ripartizione dei campi principali di questo rapporto JSON TLS:

Campi	Descrizione
organizzazione	L'organizzazione del dominio che possiede il record TLS-RPT.
e-mail	L'indirizzo e-mail a cui vengono inviati i rapporti aggregati.
data_inizio	La data di inizio del periodo di riferimento.
data_fine	La data di fine del periodo di riferimento.
politiche	Una serie di oggetti criterio che descrivono i criteri applicati durante il periodo di riferimento.
politica	Contiene informazioni sul criterio applicato.
tipo_politica	Specifica il tipo di criterio
stringa_politica	Specifica la stringa del criterio associata al criterio.
modalità	Specifica la modalità del criterio MTA-STS (Enforce/Testing).
sintesi	Contiene informazioni sintetiche sulle sessioni tentate.
numero totale di sessioni riuscite	Il conteggio totale delle sessioni TLS stabilite con successo.
numero totale di sessioni fallite	Il conteggio totale dei fallimenti della sessione TLS.
dettagli_fallimento	Un array di oggetti che forniscono dettagli su guasti specifici.
motivo	Una stringa che indica il motivo del fallimento (ad esempio, "certificato_scaduto").
conteggio	Il conteggio delle sessioni fallite per un motivo specifico.

Formato dei rapporti TLS-RPT JSON e interpretazione dei dati

Metadati del rapporto

{

  "nome dell'organizzazione": "Organizzazione MTA di invio",

  “date-range”: {

    "start-datetime": “2025-02-25T00:00:00Z”,

    "end-datetime": “2025-02-25T23:59:59Z”

  },

  "report-id": “unique-report-id-12345”

}

Questa sezione del report JSON contiene informazioni di base come il nome dell'organizzazione del mittente dell'e-mail, la data e l'ora di inizio, la data e l'ora di fine e l'ID univoco per il report TLS generato.

Dettagli sulla politica

“policy”: {

  "tipo di politica": "sts",

  "policy-string": "mode: enforce; mx: mail.example.com; max_age: 604800;"

}

Questa sezione illustra la modalità del criterio MTA-STS implementato, che in questo caso è la modalità Enforce, ma può anche essere impostata sulla modalità Testing. 

Dettagli sul fallimento

"failure-details": [

  {

    "tipo di risultato": "certificato scaduto",

    "invio-mta": "smtp.example.org",

    "receiving-mta": "mail.example.com",

    "failure-reason": "Handshake TLS fallito a causa di un certificato scaduto".

  }

]

Questa sezione è la parte più importante del rapporto TLS, in quanto illustra le ragioni della crittografia e i potenziali errori di consegna. In questo caso, l'esempio indica che un certificato scaduto è la causa del fallimento dell'handshake TLS. Ciò svolge un ruolo importante nel rilevamento degli errori durante gli handshake TLS falliti e favorisce una rapida risoluzione dei problemi per le comunicazioni TLS sicure. 

Motivi del fallimento della crittografia TLS e risoluzione dei problemi

I fallimenti della crittografia TLS possono essere dovuti a diversi motivi. Oltre alla mancanza di supporto per la crittografia da entrambe le parti, ragioni più sinistre come un attacco di downgrade SMTP possono portare al fallimento della connessione TLS. Ma i proprietari dei domini vorrebbero essere informati del fallimento della consegna. Il TLS reporting (TLS-RPT) è un protocollo che vi informerà. In caso di mancata consegna, riceverete il rapporto TLS in un file in formato JSON all'indirizzo e-mail definito nel vostro record TLS-RPT. Di seguito sono riportati alcuni motivi comuni per i fallimenti della crittografia e i suggerimenti per la risoluzione dei problemi:

1. Problemi di certificato

certificato_scaduto

Il certificato presentato dal server remoto ha superato la data di scadenza. Ciò lo rende inaffidabile per la crittografia. In questo caso, è necessario rinnovare il certificato.

certificato_non_valido_ancora

Il certificato presentato dal server remoto non è ancora valido. Ciò può essere dovuto a un orario errato del server o a un utilizzo prematuro del certificato. In questo caso, è meglio contattare il proprio fornitore di certificati.

certificato_revocato

Il certificato presentato dal server remoto è stato revocato dall'autorità di certificazione per problemi di sicurezza. In questo caso, è meglio contattare il proprio fornitore di certificati.

firma_non_valida

La catena di certificati presentata dal server remoto non è attendibile dal server di posta o dal client del mittente, il che indica un potenziale rischio per la sicurezza. In questo caso, è meglio contattare il proprio fornitore di certificati.

certificato_non_supportato

Il certificato presentato dal server remoto utilizza algoritmi di crittografia o lunghezze di chiave non supportate dal server di posta del mittente, impedendo una connessione sicura. In questo caso, è meglio contattare il proprio fornitore di certificati.

2. Mancata corrispondenza tra nome host e identità

hostname_mismatch

Il nome host specificato nel certificato del server non corrisponde al nome host del server a cui il server di posta del mittente sta cercando di connettersi. Ciò indica un possibile attacco man-in-the-middle o un problema di configurazione.

È possibile controllare i record MX nel file dei criteri MTA-STS per verificare che corrispondano al record MX del dominio.

3. Problemi di handshake e protocollo

handshake_failure

Si è verificato un problema durante il processo iniziale di handshake TLS tra il server di posta del mittente e il server di posta del destinatario, impedendo la creazione del canale sicuro. Ricontrollate se la connessione SMTP STARTTLS è stata stabilita. I motivi che contribuiscono al fallimento della crittografia possono essere diversi, come la mancanza di supporto per STARTTLS o un attacco di downgrade TLS.

4. Problemi di politica MTA-STS

mta_sts_policy_not_found

Questo errore si verifica quando il server di posta del mittente non è in grado di trovare un criterio MTA-STS per il dominio del destinatario. Controllare il file dei criteri MTA-STS. È necessario controllare il record MTA-STS per verificare che sia stato pubblicato correttamente.

mta_sts_policy_invalid

Questo errore si verifica quando il criterio MTA-STS trovato nel DNS per il dominio del destinatario non è valido, contiene errori o non è conforme alle specifiche MTA-STS. Rivedere il file dei criteri MTA-STS. Specificare una modalità di criterio MTA-STS appropriata. Può essere Nessuna, Applicare o Testare. Questa modalità indica ai server di invio come gestire le e-mail che subiscono errori di convalida dei criteri MTA-STS. 

mta_sts_policy_fetch_error

Questo errore si verifica quando il server di posta del mittente incontra un errore durante il tentativo di recuperare il criterio MTA-STS dai record DNS del dominio del destinatario. È necessario convalidare i record MTA-STS nel DNS per assicurarsi che la sintassi del record sia corretta.

mta_sts_connection_failure

Questo errore si verifica quando il server di posta del mittente tenta di stabilire una connessione sicura utilizzando MTA-STS, ma non riesce per motivi quali certificati non attendibili, suite di cifratura non supportate o altri problemi TLS. È necessario verificare la validità del certificato e assicurarsi che sia aggiornato con l'ultimo standard TLS.

mta_sts_invalid_hostname

Questo errore si verifica quando il nome host del server di posta del destinatario, specificato nel criterio MTA-STS, non corrisponde al nome host effettivo del server. È necessario controllare i record MX nel file dei criteri MTA-STS per verificare che corrispondano al record MX del dominio.

Migliori pratiche per l'implementazione di TLS-RPT

Monitorare regolarmente i rapporti TLS

I rapporti TLS devono essere monitorati regolarmente per assicurarsi di non perdere i messaggi non consegnati. È possibile farlo monitorando manualmente la casella di posta elettronica per i rapporti JSON o utilizzando uno strumento di analisi dei rapporti come PowerTLS-RPT.

Assicurarsi che il criterio MTA-STS sia configurato correttamente

Per garantire una corretta implementazione di TLS-RPT, la politica MTA-STS deve essere configurata correttamente e senza errori di sintassi. È possibile verificare il proprio record utilizzando il nostro controllore MTA-STS per questo passaggio.

Affrontare tempestivamente i problemi di crittografia

Una volta rilevate le carenze di crittografia evidenziate nel report TLS, è importante intervenire rapidamente per evitare problemi di deliverability delle e-mail in futuro. 

Utilizzare versioni sicure del protocollo TLS

L'utilizzo delle versioni più recenti e supportate del protocollo TLS è essenziale per evitare errori di crittografia indesiderati. 

Reporting SMTP TLS semplificato con PowerDMARC

L'esperienza di reporting SMTP TLS di PowerDMARC mira a migliorare la vostra sicurezza e a semplificarvi la vita con un servizio in hosting.

Rapporti TLS tradotti

I complessi report TLS-RPT JSON vengono convertiti in informazioni semplificate che possono essere sfogliate in pochi secondi o lette in dettaglio. 

Problemi di rilevamento automatico

La piattaforma PowerDMARC individua ed evidenzia il problema che state affrontando, in modo che possiate risolverlo senza perdere tempo.

Non c'è una sola cosa che mi piace della piattaforma PowerDMARC, che ha un layout facile da usare e da capire con quelle che definirei funzioni complete che consentono il controllo DMARC in hosting, appiattimento SPFdi poter espandere facilmente l'SPF per ispezionare le specifiche del record e persino il supporto completo per MTA-STS e TLS-RPT!

Dylan B (Proprietario)

Domande frequenti sulla sicurezza del livello di trasporto

1. Che cosa significa TLS?

TLS è l'acronimo di Transport Layer Security. 

2. Chi emette i certificati TLS? 

Le autorità di certificazione (CA) possono emettere certificati TLS. Il processo di emissione del certificato comprende la verifica dell'identità del titolare del certificato. Se l'identificazione ha esito positivo, il certificato viene emesso. 

3. Perché è necessario un certificato TLS?

I certificati TLS svolgono un ruolo fondamentale nella sicurezza delle comunicazioni su Internet. Aiutano a crittografare informazioni sensibili scambiate tra server web comunicanti. Alcuni dei suoi usi più comuni includono la protezione delle comunicazioni e-mail e HTTPS.

4. Qual è l'attuale standard TLS?

TLS 1.3 è l'ultima versione di Transport Layer Security. TLS-RPT può essere implementato utilizzando qualsiasi versione di TLS. Può includere versioni precedenti del protocollo o versioni future. La versione è solitamente determinata da criteri quali le capacità dei server comunicanti. 

Risorse aggiuntive

1. Generatore di record TLS-RPT 
2. Controllore di record TLS-RPT
3. MTA-STS 
4. DMARC