Le email sono davvero private? Chi può leggere i messaggi e quando

Ogni giorno inviamo e riceviamo email utilizzando servizi come Gmail, Outlook e Proton Mail, oppure programmi di posta elettronica come Thunderbird e Microsoft Outlook. Possiamo gestire i messaggi attraverso un browser, un’applicazione per smartphone o un client installato sul computer. Dietro queste modalità di accesso, però, operano protocolli differenti: SMTP per l’invio e il trasferimento dei messaggi tra server, IMAP e POP3 per accedere alla posta ricevuta, HTTPS per le interfacce Web e le comunicazioni con i servizi online.

Le connessioni possono essere protette mediante TLS (Transport Layer Security), che cifra i dati trasmessi tra i sistemi coinvolti. La presenza della crittografia, tuttavia, non significa che soltanto il mittente e il destinatario possano leggere un’email. I messaggi attraversano infrastrutture gestite da provider differenti e possono essere elaborati, analizzati e conservati su server che hanno accesso al loro contenuto.

Chi può leggere realmente le nostre email? Un provider può accedere al testo dei messaggi e agli allegati? Che differenza esiste tra proteggere una connessione con TLS e utilizzare la crittografia end-to-end? E come possiamo verificare, con strumenti alla portata di tutti, quali protezioni siano effettivamente applicate?

Il percorso di un’email: dove i messaggi possono essere letti

Immaginiamo di inviare un messaggio da Gmail a un indirizzo gestito da un altro provider. Il percorso, semplificando, comprende cinque passaggi:

1. Computer del mittente: scriviamo il messaggio nel browser o nel client di posta. Il testo è normalmente disponibile in chiaro durante la composizione.
2. Server del mittente: il messaggio raggiunge il provider attraverso HTTPS oppure SMTP con TLS. Il server può generalmente elaborarne il contenuto.
3. Trasferimento SMTP: il provider individua il server destinatario interrogando il DNS e tenta la consegna, generalmente utilizzando STARTTLS per proteggere il collegamento.
4. Server del destinatario: il messaggio viene ricevuto, eventualmente analizzato da filtri antispam e antivirus, quindi archiviato.
5. Computer del destinatario: l’utente legge l’email via HTTPS, IMAP con TLS o altri protocolli protetti.

Il punto fondamentale è che il protocollo TLS protegge le comunicazioni tra due estremità di una connessione, non il contenuto durante la sua elaborazione sui server. Un provider potrebbe quindi avere accesso tecnico ai messaggi senza che ciò implichi che il personale li legga o che siano utilizzati per finalità commerciali.

Per approfondire il funzionamento dei protocolli, rimandiamo alla nostra guida sulle differenze tra SSL, TLS e STARTTLS nella posta elettronica.

Prima prova pratica: scoprire quali server hanno trasportato un’email

Ogni messaggio contiene intestazioni tecniche, o header, che descrivono parte del suo percorso: possiamo esaminarle senza installare programmi.

In Gmail basta aprire un’email ricevuta, premere il pulsante con i tre puntini accanto a Rispondi e scegliere Mostra originale. In Thunderbird è possibile utilizzare CTRL+U per visualizzare il sorgente del messaggio.

Tra le informazioni disponibili cerchiamo le righe che iniziano con Received:. Un esempio, con nomi e indirizzi dimostrativi, potrebbe essere il seguente:

Received: from mail.example.net (192.0.2.20)
 by mx.example.org with ESMTPS
 id 123456
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384)

La dicitura ESMTPS e i dettagli TLS1_3 indicano che il server che ha aggiunto quella riga dichiara di aver ricevuto il messaggio attraverso una connessione SMTP protetta.

Le intestazioni Received sono generalmente aggiunte in testa: leggendo dal basso verso l’alto possiamo ricostruire la sequenza dei passaggi. Bisogna però distinguere le righe inserite dai server affidabili da quelle eventualmente falsificate da un mittente.

Seconda prova: verificare se un server SMTP supporta STARTTLS

Con OpenSSL, disponibile su Linux e installabile anche su Windows, possiamo interrogare direttamente un server SMTP senza inviare alcuna email. Per prima cosa individuiamo i server di posta del dominio da analizzare. Da PowerShell, in Windows, si può ad esempio digitare quanto segue:

Resolve-DnsName gmail.com -Type MX

Su Linux possiamo utilizzare:

dig gmail.com MX +short

Scelto uno degli host MX restituiti, sostituiamo mx.example.net nel comando seguente (in Windows, OpenSSL può essere scaricato facendo riferimento al repository GitHub ufficiale):

openssl s_client -starttls smtp \
-connect mx.example.net:25 \
-servername mx.example.net \
-verify_return_error

Se il collegamento viene stabilito, OpenSSL mostra informazioni sulla sessione TLS, sul certificato digitale e sull’algoritmo crittografico negoziato.

Un risultato che indica Protocol: TLSv1.3 e un codice di verifica del certificato pari a zero è un segnale positivo, purché sia verificata anche la corrispondenza tra certificato e nome del server. L’opzione -verify_return_error interrompe la procedura quando emergono errori nella verifica della catena di certificazione.

Se la connessione fallisce, non significa automaticamente che il server sia insicuro: la porta 25 potrebbe essere bloccata dalla rete utilizzata oppure il server potrebbe applicare restrizioni.

STARTTLS può essere aggirato? Perché esistono MTA-STS e DANE

Quando inviamo un’email da Gmail a un indirizzo gestito da un altro provider, il server Google deve stabilire una connessione con il server SMTP del destinatario. Per proteggere il trasferimento del messaggio, i due sistemi possono utilizzare STARTTLS, un comando del protocollo SMTP che permette di passare da una connessione inizialmente non cifrata a una protetta mediante TLS.

Il server mittente si collega al server destinatario e invia il comando EHLO per conoscere le funzionalità disponibili. Se il destinatario supporta STARTTLS, lo comunica nella risposta; il mittente può quindi richiedere l’attivazione di TLS e, una volta completata la negoziazione crittografica, trasmettere il messaggio attraverso il canale protetto.

Dove nasce il problema? Nel normale trasferimento SMTP, STARTTLS è spesso utilizzato in modalità opportunistica: il server mittente prova cioè ad attivare la crittografia, ma può essere configurato per consegnare comunque il messaggio se il server destinatario non la supporta.

Un aggressore capace di intercettare e modificare la comunicazione tra i due server potrebbe sfruttare proprio questa caratteristica: poiché la prima parte dello scambio SMTP avviene prima dell’attivazione di TLS, l’aggressore potrebbe eliminare dalla risposta del destinatario la riga che annuncia STARTTLS.

Il server mittente potrebbe così convincersi che il destinatario non supporti connessioni cifrate e procedere con l’invio in chiaro. La tecnica prende il nome di attacco di downgrade STARTTLS.

Come impedire che le email viaggino senza crittografia

Per evitare che un attaccante riesca a disattivare la protezione TLS durante il trasferimento delle email, esistono due soluzioni:

• MTA-STS (Mail Transfer Agent Strict Transport Security): permette al dominio che riceve le email di comunicare agli altri server: “Accettate di inviarci messaggi soltanto attraverso connessioni cifrate e verificate“. Se un server mittente supporta MTA-STS e non riesce a stabilire una connessione TLS sicura, deve rinviare la consegna anziché spedire il messaggio in chiaro. Il meccanismo è descritto nel documento RFC 8461.
• DANE (DNS-Based Authentication of Named Entities): raggiunge un obiettivo simile utilizzando il DNS, il sistema che permette di individuare gli indirizzi IP dei server associati a un dominio. Attraverso informazioni pubblicate nel DNS e protette da DNSSEC, il server mittente può verificare di comunicare con il destinatario corretto e impedire che un aggressore lo costringa a rinunciare alla crittografia. Il funzionamento è definito nell’RFC 7672.

Entrambi i meccanismi servono a impedire che un’email sia trasmessa in chiaro quando dovrebbe viaggiare su una connessione protetta. Funzionano però soltanto se il server mittente supporta e applica la tecnica.

Inoltre, MTA-STS e DANE proteggono il trasferimento delle email, non impediscono ai provider di leggerle. Quando il messaggio arriva sul server destinatario, di norma il provider può accedere al contenuto della mail. Per evitare anche questa possibilità serve la crittografia end-to-end, che protegge il messaggio prima ancora che sia inviato.

Terza prova: controllare MTA-STS di un dominio

Possiamo effettuare un controllo aggiuntivo per verificare se un provider dichiara di voler ricevere le email soltanto attraverso connessioni TLS sicure. Per farlo basta interrogare il DNS del dominio e cercare la presenza di una configurazione MTA-STS.

Su Windows, apriamo PowerShell e digitiamo quanto segue:

Resolve-DnsName _mta-sts.gmail.com -Type TXT

Se il dominio pubblica un record MTA-STS, possiamo consultare le regole effettive utilizzando il comando:

curl https://mta-sts.gmail.com/.well-known/mta-sts.txt

Tra le informazioni restituite, quella più interessante è mode: enforce: significa che il dominio richiede ai server mittenti compatibili con MTA-STS di utilizzare connessioni TLS correttamente autenticate. Se non riescono a stabilirle, devono rinviare la consegna invece di trasmettere il messaggio in chiaro.

La presenza di MTA-STS non garantisce che tutti i messaggi viaggino cifrati, perché anche il server mittente deve supportare il meccanismo. Soprattutto, non impedisce al provider destinatario di accedere al contenuto delle email ricevute!

Quarta prova: verificare l’uso di DANE attraverso i record DNS

Come abbiamo spiegato in precedenza, un’altra protezione contro l’intercettazione delle email è DANE, che permette ai server di posta di verificare, attraverso informazioni pubblicate nel DNS e protette da DNSSEC, l’identità del server destinatario e la corretta attivazione della connessione cifrata.

Per controllare se un server SMTP pubblica le informazioni necessarie al fine dell’uso di DANE, possiamo interrogare i suoi record DNS TLSA. Su Linux, dopo aver individuato il nome del server MX del dominio, basta eseguire:

dig +dnssec _25._tcp.mx.example.net TLSA

Anche in questo caso, è necessario sostituire mx.example.net con il nome effettivo del server di posta. Se nella risposta compare un record TLSA, significa che il server pubblica informazioni crittografiche utilizzabili dai mittenti compatibili con DANE per verificarne l’identità.

Anche qui, la presenza del record non dimostra che DANE sia correttamente configurato. Le informazioni devono essere protette da una catena DNSSEC valida e il server mittente deve supportare DANE e applicarne le verifiche.

Come MTA-STS, anche DANE protegge il trasferimento delle email tra server, non il contenuto dei messaggi una volta ricevuti dal provider. Non sostituisce quindi la crittografia end-to-end.

Crittografia a riposo: il provider può leggere le email archiviate?

Finora abbiamo esaminato il trasporto. Ma cosa accade quando il messaggio raggiunge la casella?

Molti provider utilizzano la crittografia a riposo per proteggere i dati conservati sui server. Questo non significa che il fornitore sia tecnicamente impossibilitato a leggerli: potrebbe controllare le chiavi necessarie alla decifratura.

La situazione cambia con la zero-access encryption, nella quale il contenuto viene conservato utilizzando chiavi che, secondo il modello di sicurezza implementato, il provider non può utilizzare autonomamente per recuperare i messaggi archiviati.

La distinzione emerge chiaramente nella documentazione di Proton Mail: quando un messaggio tradizionale arriva da Gmail, il server Proton può tecnicamente riceverlo in chiaro prima di cifrarlo per la conservazione. Tra due utenti Proton, invece, il contenuto può essere cifrato end-to-end già sul dispositivo del mittente.

La zero-access encryption riguarda soprattutto l’impossibilità di leggere i dati archiviati mentre la end-to-end encryption ha a che vedere con la protezione del contenuto durante l’intero scambio. Abbiamo già approfondito le differenze tra questi servizi nell’articolo ProtonMail contro Tutanota e analizzato un’altra implementazione nella guida alla crittografia email di Infomaniak.

Antispam, antivirus e assistenti AI: chi analizza i messaggi?

I servizi email offrono ricerca nel contenuto, classificazione automatica, rilevamento del phishing, scansione degli allegati e, sempre più spesso, funzionalità basate sull’intelligenza artificiale.

Alcune di queste operazioni richiedono l’accesso al testo o a una sua rappresentazione elaborabile: se il provider può analizzare i messaggi in chiaro, può tecnicamente sottoporli anche a sistemi automatici, secondo le funzionalità e le condizioni dichiarate.

Un servizio basato su crittografia end-to-end deve invece ricorrere a soluzioni differenti, come elaborazioni sul dispositivo dell’utente, indici locali o analisi limitate ai metadati.

Per valutare la riservatezza di un provider conviene quindi leggere la documentazione tecnica e le condizioni sul trattamento dei dati, verificando soprattutto dove avvengono indicizzazione, scansione degli allegati e funzioni AI: l’utilizzo di TLS non fornisce alcuna risposta a queste domande.

Neppure OpenPGP e S/MIME nascondono tutte le informazioni

Con OpenPGP o S/MIME, il contenuto del messaggio può essere cifrato per il destinatario prima della trasmissione. In questo modo, i server intermedi non devono possedere le chiavi necessarie per leggerlo.

Restano tuttavia visibili informazioni indispensabili al funzionamento della posta elettronica: indirizzi utilizzati per la consegna, informazioni temporali e parte delle intestazioni. Nell’uso ordinario di OpenPGP, anche l’oggetto del messaggio non è protetto dalla cifratura end-to-end.

Una prova banale consiste nell’inviare a un proprio secondo account un’email con oggetto generico e corpo cifrato tramite OpenPGP, per esempio usando Thunderbird. Aprendo il sorgente del messaggio ricevuto, si possono confrontare le intestazioni leggibili con il contenuto MIME cifrato. Per completare la prova, entrambi gli account devono disporre delle rispettive chiavi OpenPGP.

È una dimostrazione concreta del fatto che crittografia del contenuto e anonimato sono proprietà differenti, come abbiamo osservato anche nell’approfondimento su Proton Mail e identificazione degli utenti.

Come rendere davvero più private le proprie email: Gmail, Outlook e Thunderbird

Le verifiche descritte permettono di distinguere tre livelli di sicurezza: la protezione delle connessioni TLS, la crittografia dei messaggi archiviati sui server e la crittografia end-to-end, che rende il contenuto leggibile soltanto a chi possiede le chiavi necessarie per decifrarlo.

Ma come possiamo ottenere quest’ultima protezione utilizzando i servizi e i programmi di posta elettronica più diffusi? Le possibilità cambiano a seconda dell’applicazione e del tipo di account.

• Gmail: per gli account personali, una soluzione consiste nell’utilizzare Mailvelope, estensione per browser che integra OpenPGP nell’interfaccia Web di Gmail. Dopo aver generato una coppia di chiavi e acquisito la chiave pubblica del destinatario, è possibile cifrare il contenuto prima dell’invio. Attenzione alla modalità riservata di Gmail: permette di limitare inoltro, copia e download e di impostare una scadenza, ma non impedisce a Google di accedere tecnicamente al contenuto. Per alcune edizioni aziendali e scolastiche di Google Workspace è inoltre disponibile la Client-side encryption, che cifra i messaggi nel browser prima di trasmetterli ai sistemi Google.
• Outlook.com: anche la Webmail Microsoft può essere utilizzata con Mailvelope per inviare messaggi cifrati tramite OpenPGP. Un’altra possibilità, disponibile con abbonamenti Microsoft 365 Personal o Family idonei, consiste nello scegliere Opzioni, Crittografa durante la composizione di un messaggio. Microsoft offre anche la modalità Non inoltrare, che limita alcune operazioni consentite al destinatario. Si tratta però di una protezione gestita attraverso i servizi Microsoft 365, non equivalente alla crittografia OpenPGP con chiavi private controllate dagli interlocutori.
• Microsoft Outlook per Windows: il client di posta, sia nella versione classica sia nel nuovo Outlook nelle configurazioni supportate, permette di utilizzare S/MIME per cifrare e firmare digitalmente i messaggi. Occorre disporre di un certificato personale con relativa chiave privata e conoscere il certificato pubblico del destinatario. Nel client classico la configurazione si trova in File, Opzioni, Centro protezione, Impostazioni Centro protezione, Sicurezza posta elettronica. Il nuovo Outlook dispone invece delle opzioni S/MIME nelle impostazioni della posta, quando supportate dall’account e dalla configurazione. Microsoft illustra le procedure nella documentazione ufficiale sulla crittografia S/MIME. S/MIME permette di proteggere il contenuto indipendentemente dai normali meccanismi TLS utilizzati per trasportare i messaggi.
• Mozilla Thunderbird: rappresenta una delle soluzioni più accessibili per utilizzare OpenPGP senza installare estensioni aggiuntive. Il supporto è integrato direttamente nel programma, insieme a quello per S/MIME. Per iniziare basta aprire Impostazioni account, Crittografia end-to-end, Aggiungi chiave e creare una coppia di chiavi OpenPGP. Successivamente si acquisisce e si verifica la chiave pubblica del destinatario e si attiva la crittografia durante la composizione del messaggio. La guida ufficiale di Thunderbird illustra l’intera procedura (avevamo già spiegato come inviare email crittografate con Thunderbird e OpenPGP). Il vantaggio è che la protezione funziona anche con normali account Gmail, Outlook.com e altri provider configurati nel client, purché mittente e destinatario utilizzino strumenti compatibili.

Quale soluzione scegliere?

Per chi utilizza Gmail o Outlook.com direttamente dal browser, Mailvelope permette di sperimentare OpenPGP senza cambiare provider.

Chi preferisce un client desktop può utilizzare Thunderbird, mentre negli ambienti professionali Outlook con S/MIME costituisce una soluzione particolarmente interessante quando l’organizzazione gestisce già certificati digitali.

I servizi che offrono crittografia end-to-end integrata, come Proton Mail e Tuta, possono invece semplificare la protezione delle comunicazioni tra utenti dello stesso servizio. Ne abbiamo discusso nel nostro confronto tra Proton Mail e Tuta.

Qualunque sia la soluzione adottata, bisogna ricordare che la crittografia del contenuto non nasconde automaticamente mittente, destinatario, orario e altre informazioni necessarie alla consegna. Anche l’oggetto del messaggio può rimanere leggibile: per comunicazioni particolarmente riservate è quindi preferibile utilizzare un oggetto generico ed evitare informazioni riservate o personali nelle intestazioni.

Infine, le chiavi private devono essere custodite con attenzione, protette mediante credenziali robuste e conservate in copie di sicurezza affidabili. Perdere una chiave privata può significare perdere definitivamente la possibilità di leggere i messaggi cifrati.

Da ricordare, come “pillola” finale, che TLS protegge il percorso dell’email, mentre la crittografia end-to-end protegge il messaggio stesso. Se vogliamo impedire anche ai server intermedi di conoscere il contenuto delle nostre comunicazioni, dobbiamo ricorrere alla seconda soluzione, verificando sempre chi controlla le chiavi e dove avvengono materialmente cifratura e decifratura.