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. La Transport Layer Security (TLS) è una pietra miliare per garantire la riservatezza e l'integrità dei dati trasmessi attraverso le reti.
Diversi protocolli aiutano a crittografare i canali dei messaggi SMTP per impedire ai cyberattaccanti di intercettare le comunicazioni e-mail. Tra questi vi sono STARTTLS, DANE e MTA-STS. Tuttavia, quando i tentativi di crittografia falliscono durante l'utilizzo 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 sicurezza delle e-mail.
Cos'è TLS-RPT?
TLS-RPT è l'acronimo di Transport Layer Security Reporting. È uno standard per segnalare i problemi di consegna delle e-mail che si verificano quando un'e-mail non è crittografata 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, spesso 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.
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 solo nelle comunicazioni SMTP, 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.
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. Con MTA-STS abilitato, gli aggressori non riescono a consegnare i messaggi in chiaro quando la connessione fallisce.
Ma i proprietari dei domini vorrebbero sapere se la consegna non è andata a buon fine. La segnalazione TLS (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.
Perché avete bisogno della segnalazione SMTP TLS?
I proprietari di domini devono essere sempre informati sulle email di
problemi di consegna 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. TLS-RPT
- Per ricevere rapporti di feedback che evidenziano il vostro tipo di polizza e
- Per identificare il motivo dei fallimenti della crittografia TLS
- Per ottenere visibilità sui canali e-mail
- Per risolvere i problemi di consegna
Passi per l'impostazione di TLS-RPT
È possibile attivare 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: Selezionare uno strumento per la generazione 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.
Esempio di record TLS-RPT
Sintassi: v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com;
Analizziamo i 2 componenti del record di segnalazione TLS fornito:
- v=TLSRPTv1: Questo tag specifica la versione del protocollo TLS-RPT utilizzata. In questo caso, "TLSRPTv1" indica la prima versione del protocollo.
- rua=mailto:tlsrpt@yourdomain.com: 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 "maito:" 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 usati anche in un singolo record, separati da una virgola.
Esempio: v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://tlsreport.example.com;
Nota: In pratica, si sostituisce "tuodominio.com" con il nome del dominio effettivo in cui si desidera ricevere i rapporti.
Formato di segnalazione TLS
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": "smtp-tls-reporting@organization.com",
"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
}
Ecco la ripartizione dei campi principali di questo rapporto JSON TLS:
| Campi | Descrizione |
| organizzazione | L'organizzazione del dominio che possiede il record TLS-RPT. |
| 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. |
Motivi e tipi di fallimento della crittografia TLS
Problemi di certificato
| Tipi di fallimento | Motivi | Possibili suggerimenti per la risoluzione dei problemi |
| certificato_scaduto | Il certificato presentato dal server remoto ha superato la data di scadenza. Ciò lo rende inaffidabile per la crittografia. | 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. | Contattare il fornitore del certificato. |
| certificato_revocato | Il certificato presentato dal server remoto è stato revocato dall'autorità di certificazione per problemi di sicurezza. | Contattare il fornitore del certificato. |
| 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. | Contattare il fornitore del certificato. |
| 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. | Contattare il fornitore del certificato. |
Mancata corrispondenza tra nome host e identità
| Tipo di guasto | Motivo | Possibili suggerimenti per la risoluzione dei problemi |
| 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. | Controllare i record MX nel file dei criteri MTA-STS per verificare che corrispondano al record MX del dominio. |
Problemi di handshake e protocollo
| Tipi di fallimento | Motivi | Possibili suggerimenti per la risoluzione dei problemi |
| 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. | Verificare che la connessione SMTP STARTTLS sia 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. |
Problemi di politica MTA-STS
| Tipi di fallimento | Motivi | Possibili suggerimenti per la risoluzione dei problemi |
| 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. | Esaminare il file dei criteri di MTA-STS.
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. | Esaminare il file dei criteri di MTA-STS.
Specificare una modalità di criterio MTA-STS appropriata. Può essere Nessuna, Applicare o Testare. Indica ai server di invio come gestire le e-mail che subiscono errori di convalida dei criteri MTA-STS. Per saperne di più sulle modalità della politica , cliccate qui. |
| 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. | Convalidare i record MTA-STS nel DNS per verificare 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 fallisce per motivi quali certificati non attendibili, suite di cifratura non supportate o altri problemi TLS. | Controllate la validità del vostro certificato, assicurandovi che il certificato 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, come specificato nel criterio MTA-STS, non corrisponde al nome host effettivo del server. | Controllare i record MX nel file dei criteri MTA-STS per verificare che corrispondano al record MX del dominio. |
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 funzionalità complete che consentono il controllo DMARC in hosting, l'appiattimento SPF, la possibilità di espandere facilmente l'SPF include 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 rilascia 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 le 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
- Codici di errore SMTP Yahoo spiegati - 1 maggio 2024
- SPF Softfail Vs Hardfail: Qual è la differenza? - 26 aprile 2024
- L'FTC segnala che l'e-mail è un mezzo popolare per le truffe di impersonificazione - 16 aprile 2024