Nell’ambito dell’email security esistono diversi protocolli volti a garantire l’autenticità, l’integrità e la riservatezza delle comunicazioni, tra i più importanti ci sono:

• SMTP (Simple Mail Transfer Protocol): è il protocollo di base utilizzato per inviare e ricevere email, tuttavia, per impostazione predefinita, SMTP non offre meccanismi di autenticazione e sicurezza. Pertanto, molte implementazioni incorporano estensioni relative a STARTTLS per crittografare le comunicazioni tra i server di posta elettronica.
• SSL/TLS (Secure Sockets Layer/Transport Layer Security): sono protocolli crittografici utilizzati per garantire la riservatezza e l’integrità delle comunicazioni tra client e server. In questo caso il protocollo STARTTLS consentirà di avviare una connessione sicura SSL/TLS durante la trasmissione delle email. Si noti che il protocollo SSL è ormai in disuso in quanto poco sicuro; pertanto, come best practice si consiglia il protocollo TLS alla versione 1.2. La versione del TLS 1.3 sarebbe in realtà quella desiderata, tuttavia, non essendo in grado di “comunicare” con le sue versioni precedenti può creare molti problemi di comunicazione con chi non adotta tale protocollo (purtroppo ancora poco diffuso).
• PGP (Pretty Good Privacy) / GPG (GNU Privacy Guard): sono protocolli di crittografia end-to-end utilizzati per cifrare e decifrare i contenuti delle email. Consentono agli utenti di proteggere il contenuto delle loro comunicazioni durante la trasmissione.
• S/MIME (Secure/Multipurpose Internet Mail Extensions): è un protocollo di crittografia che fornisce sicurezza alle email utilizzando certificati digitali che firmano e cifrano i messaggi. È spesso utilizzato per garantire la riservatezza e l’autenticità delle email.
• DNSSEC (Domain Name System Security Extensions): questo protocollo non è specificamente legato alle email tuttavia la sicurezza del DNS è cruciale per i protocolli di SPF, DKIM e DMARC. DNSSEC previene gli attacchi di spoofing e garantisce l’integrità delle informazioni.

Quando viene inviata un’email, il server del destinatario esegue alcuni controlli per verificare se il messaggio risulta legittimo e inviato da un mittente autorizzato. Questi controlli sono possibili attraverso l’implementazione dei protocolli SPF, DKIM e DMARC:

• SPF (Sender Policy Framework): è un protocollo di autenticazione che verifica se un server di posta elettronica è effettivamente autorizzato a inviare messaggi per un determinato dominio. Come si evince dalla figura 5, Il mittente pubblicherà il record SPF nel DNS, specificando quali sono i server autorizzati a inviare email per proprio conto, così, quando un server di posta riceverà un messaggio, potrà verificare l’autenticità del mittente controllandone il record SPF.

Nota. Quando un messaggio viene forwardato l’SPF authentication fallisce.

Questo protocollo risulta particolarmente efficace contro gli attacchi di tipo spoofing e phishing.

• DKIM (Domain-Keys Identified Mail): il protocollo utilizza la firma digitale per verificare l’autenticità dell’email ricevuta e confermare che non sia stata manomessa durante la consegna. Il protocollo prevede che il server SMTP del mittente aggiunga una firma (signature) con chiave privata negli header dei messaggi di posta. Questa firma potrà confermare che l’email è stata realmente inviata dal mittente dichiarato e che il contenuto non è stato manomesso durante la trasmissione. Se il server destinatario prevede la verifica della firma, verrà eseguita un’interrogazione DNS del dominio mittente per ottenere la chiave pubblica, con la quale sarà possibile verificare il messaggio e garantirne così l’integrità e la non compromissione della mail. In figura 6 il funzionamento descritto.

Questo protocollo è particolarmente efficace contro gli attacchi “man in the middle”. SPF e DKIM possono cooperare ma non necessariamente devono essere abbinati.

• DMARC (Domain-based Message Authentication, Reporting, and Conformance): è un protocollo che, utilizzando SPF e DKIM, fornisce indicazioni su come dovranno essere gestite le email non autenticate specificando quale azione si dovrà intraprendere in caso non ci sia una corretta la configurazione:
  • None à nessun’azione, il messaggio verrà analizzato dal server di posta ed eventualmente consegnato.
  • Quarantine à il messaggio sarà classificato come non legittimo e quarantenato. Il messaggio in questo caso è ancora recuperabile per un certo periodo (tendenzialmente non oltre i 30 giorni).
  • Reject à il messaggio sarà respinto e non recuperabile.

In figura 7 si può osservare il funzionamento del DMARC.

Sarà compito del DNS Admin configurare correttamente la politica di “pass” dell’email e quando questa invece non dovrà essere consegnata e perché settando quindi il record con una delle policy sopra descritte (none, quarantine o reject). Il DMARC include, inoltre, anche un meccanismo di reporting contenente informazioni dettagliate sul flusso mail aiutando così gli amministratori a monitorare e migliorare la configurazione della sicurezza dei server di posta.

In sintesi, SPF, DKIM e DMARC lavorano insieme per garantire l’autenticità e l’integrità del messaggio verificando che questi sia inviato effettivamente dal dominio dichiarato e che quindi il mail server sia effettivamente autorizzato. L’implementazione corretta e combinata di tutti i protocolli sin qui descritti contribuisce a rafforzare la sicurezza delle comunicazioni via email, proteggendo gli utenti da minacce come spam, phishing e spoofing.

Questo articolo è stato estratto dal white paper “Email Security: Intelligenza Artificiale, Protocolli e Best Practice Contro gli Attacchi Informatici” disponibile in maniera libera e gratuita al seguente link: https://www.ictsecuritymagazine.com/pubblicazioni/email-security-intelligenza-artificiale-protocolli-e-best-practice-contro-gli-attacchi-informatici/

Articolo a cura di Fabrizio Giorgione

Profilo Autore

Fabrizio Giorgione è nato a Napoli (NA) nel 1992. Si è laureato in ingegneria informatica presso l’università degli studi del Sannio il 17 dicembre del 2018 con una tesi dal titolo: “Analisi della superficie di un sistema SCADA”. Ha sviluppato, presso il laboratorio ISWATlab, un’applicazione Android denominata “Privacy Guard” la quale valuta il rischio di privacy leakage, ovvero il furto di informazioni, sugli smartphone (http://www.iswatlab.eu/?page_id=499). Ha effettuato il tirocinio presso lo “ZLab” di “Cse Cyber Sec” nell’ambito “SOC”, “Forensic” e “Malware Analysis”. Attualmente lavora presso la società di “NTT DATA” come “Cyber security Analyst” nel SOC di Napoli. Il suo compito è quello di effettuare analisi di log, di malware e di prevenire minacce interne ed esterne alla sua azienda e ai clienti della società. Si è occupato, inoltre, del montaggio e della gestione di sonde IDS/IPS presso Telecom Italia nella sede di Roma (RM).

https://www.ictsecuritymagazine.com/articoli/email-security-i-protocolli-di-sicurezza-che-garantiscono-lautenticita-lintegrita-e-la-riservatezza-delle-comunicazioni/