Indice
- I tre significati di «email cifrata»
- Cifratura di trasporto: necessaria, non sufficiente
- End-to-end: PGP vs S/MIME
- Cifratura ad accesso zero del provider
- Il problema dei metadati che tutti saltano
- Dove si collocano davvero i grandi provider
- Un quadro decisionale
I tre significati di «email cifrata»
«Email cifrata» è una delle espressioni più abusate del mercato della privacy, perché quasi ogni provider può affermarla onestamente intendendo cose completamente diverse. Ci sono tre strati di cifratura distinti nell'email, e difendono contro tre avversari diversi:
- Cifratura di trasporto (TLS / STARTTLS) — la connessione tra due server di posta è cifrata. Ciò ferma un origliatore passivo sul cavo. Oggi è quasi universale ed è il minimo indispensabile, non una funzione.
- Cifratura end-to-end (PGP o S/MIME) — il corpo del messaggio è cifrato sul dispositivo del mittente con la chiave pubblica del destinatario, così che solo la chiave privata del destinatario possa aprirlo. Nessun server del percorso può leggerlo.
- Cifratura ad accesso zero del provider — il provider archivia la tua casella cifrata con chiavi derivate dalla tua password, così che nemmeno lui possa leggere i messaggi presenti nel tuo account.
Quando un provider di consumo dice «la tua email è cifrata», intende quasi sempre lo strato 1, a volte lo strato 1 più la cifratura del disco a riposo. Quando un ingegnere attento alla privacy chiede email cifrata, intende quasi sempre lo strato 2 o 3. Quel divario è tutto il tema di questa guida.
Cifratura di trasporto: necessaria, non sufficiente
TLS — di solito negoziato su SMTP con STARTTLS — cifra il salto tra due server di posta. Il suo valore è reale: impedisce a chi sorveglia la rete di leggere la tua posta in volo, e l'infrastruttura moderna lo usa quasi ovunque.
Ma TLS è salto per salto, non end-to-end. Un messaggio attraversa tipicamente più server tra mittente e destinatario, e a ogni salto viene decifrato, elaborato e ri-cifrato per la tappa successiva. Ciò significa che ogni server della catena — il tuo provider, quello del destinatario e ogni relay intermedio — tratta il messaggio in chiaro. La cifratura di trasporto protegge il messaggio dagli estranei sul cavo; non fa nulla per proteggerlo dai provider stessi.
C'è un secondo trucco: STARTTLS è opportunistico per impostazione predefinita. Se il server ricevente non annuncia TLS, molti mittenti ripiegano silenziosamente sulla consegna in chiaro invece di fallire. Quindi «usiamo TLS» non garantisce nemmeno che un dato messaggio sia stato cifrato sull'intero percorso. Per questo la cifratura di trasporto, per quanto essenziale, è il pavimento e non il soffitto.
End-to-end: PGP vs S/MIME
La cifratura end-to-end (E2EE) sposta la cifratura agli estremi. Il mittente cifra il messaggio con la chiave pubblica del destinatario; solo la chiave privata del destinatario può decifrarlo. Poiché i server intermedi non detengono mai la chiave privata, nessuno può leggere il corpo — né il tuo provider, né un relay, né il provider del destinatario. È lo stesso modello a chiave pubblica che sostiene i gestori di password da CLI e la gestione delle chiavi che trattiamo per gli sviluppatori; la differenza sta in chi gestisce la distribuzione delle chiavi.
Dominano due standard, e la loro differenza riguarda interamente fiducia e distribuzione delle chiavi:
PGP (OpenPGP). Una «rete di fiducia» decentralizzata. Gli utenti generano le proprie coppie di chiavi e scambiano direttamente le chiavi pubbliche, verificandole fuori banda (un'impronta al telefono, una chiave firmata da un contatto comune). È massimamente flessibile e non richiede un'autorità centrale, ma la distribuzione delle chiavi è manuale, da cui la fama di attrito di PGP. È lo standard tra privati, giornalisti e comunità open source.
S/MIME. Le chiavi pubbliche sono legate a identità tramite certificati emessi da un'autorità di certificazione (CA) centrale. Ciò semplifica molto il dispiegamento in un'organizzazione gestita — l'IT fornisce i certificati centralmente — ma lega la tua fiducia a quella gerarchia di CA. S/MIME è la scelta abituale in aziende e amministrazioni, dove esiste già una PKI gestita.
Entrambi offrono la stessa garanzia centrale: un messaggio che nessun server intermedio può leggere, più una firma digitale che prova il mittente e l'assenza di alterazioni. Il costo, in entrambi i casi, è che anche il destinatario deve partecipare. Non puoi inviare in modo trasparente un messaggio E2EE a chi non ha una chiave.
Cifratura ad accesso zero del provider
C'è un terzo modello che aggira il dolore della distribuzione delle chiavi per il caso comune di una casella privata: la cifratura ad accesso zero presso il provider.
Qui il provider cifra la tua casella archiviata con chiavi derivate dalla tua password, sul tuo dispositivo, così che il server memorizzi solo testo cifrato per il tuo account. Nemmeno il provider può leggere la posta a riposo. Proton Mail è l'implementazione più nota: i messaggi tra utenti Proton sono cifrati end-to-end per impostazione predefinita, e l'intera casella è tenuta sotto cifratura ad accesso zero, così che Proton stesso non possa leggerla.
Il limite onesto sta nella natura dell'email. Quando un utente Proton scrive a un utente Gmail, il messaggio non può essere cifrato end-to-end a meno che l'utente Gmail abbia anch'esso PGP, perché l'altro estremo non ha chiave. Proton lo gestisce lasciandoti inviare un messaggio protetto da password a un non utente: il destinatario lo apre tramite un link e una password che condividi separatamente. È un ponte reale, ma la password va condivisa tramite un altro canale — lo stesso vincolo di fondo di PGP, confezionato in modo più comodo.
La cifratura ad accesso zero attrae perché ti dà una casella leggibile, ricercabile sul dispositivo, senza configurazione, che il provider non può comunque leggere — senza costringere ogni corrispondente a gestire chiavi.
Il problema dei metadati che tutti saltano
Questo è il punto più importante e più ignorato di ogni discussione onesta sull'email cifrata: la cifratura protegge il contenuto, non i metadati.
Anche con una cifratura end-to-end impeccabile, quanto segue di norma viaggia in chiaro e può essere registrato dal tuo provider, da quello del destinatario e dalla rete:
- chi ha inviato il messaggio e chi l'ha ricevuto,
- la marca temporale,
- la dimensione del messaggio,
- e, in molte implementazioni, l'oggetto.
Quindi la cifratura risponde a «cosa diceva il messaggio», ma non a «chi parla con chi, quando e con quale frequenza». Per un modello di minaccia in cui nascondere i tuoi contatti conta — non solo le tue parole — la cifratura del contenuto da sola è insufficiente. I provider che minimizzano la conservazione dei metadati, e gli strumenti a livello di rete, affrontano un'altra parte del problema. Tratta il limite dei metadati come un fatto di progetto dell'email, non come un difetto di un singolo provider, e pianifica di conseguenza.
Dove si collocano davvero i grandi provider
| Provider | In transito | A riposo | End-to-end di default | Il provider può leggere la tua posta |
|---|---|---|---|---|
| Gmail (consumo) | TLS | Sì (Google detiene le chiavi) | No | Sì |
| Outlook / Microsoft 365 (consumo) | TLS | Sì (Microsoft detiene le chiavi) | No | Sì |
| Gmail Workspace + CSE / S/MIME | TLS | Sì | Solo se configurato | Ridotto con CSE |
| Proton Mail | TLS | Accesso zero (le chiavi le hai tu) | Sì, tra utenti Proton | No |
Lo schema è costante: i servizi di consumo cifrano in transito e a riposo ma detengono le chiavi, quindi possono — e per funzioni e richieste legali, lo fanno — leggere i contenuti. Ottenere l'end-to-end su Gmail o Outlook è possibile ma richiede una configurazione deliberata (S/MIME, o cifratura lato client su piani a pagamento specifici). Proton Mail è costruito E2EE-e-accesso-zero per impostazione predefinita, il che lo rende il provider più citato quando «email cifrata» indica lo strato 2 o 3 anziché lo strato 1.
Una nota sulla verifica, nello spirito della sovranità dei dati: un'affermazione di cifratura che non puoi ispezionare è un'asserzione, non una garanzia. I client open source — Proton pubblica i suoi — permettono a revisori indipendenti di confermare che le chiavi sono generate sul tuo dispositivo e che il testo in chiaro non raggiunge mai il server. Preferisci provider le cui affermazioni siano verificabili a quelli che le enunciano soltanto.
Un quadro decisionale
Smetti di chiedere «quale email è più cifrata» e chiedi invece «chi non deve poter leggere questo, e il destinatario è disposto a partecipare?»
La cifratura di trasporto basta quando il contenuto è ordinario e la tua unica preoccupazione è un origliatore di rete. Ogni provider serio te la dà già; non c'è nulla da configurare.
Usa l'end-to-end (PGP o S/MIME) quando messaggi specifici devono essere illeggibili per ogni server del percorso e il destinatario può detenere una chiave — un collega, la fonte di un giornalista, un'organizzazione con S/MIME gestito. Accetta il passaggio di scambio chiavi come prezzo della garanzia.
Usa un provider ad accesso zero come Proton Mail quando vuoi tutta la tua casella illeggibile per il provider senza costringere ogni corrispondente a usare PGP, con un ripiego protetto da password per il messaggio cifrato occasionale verso un esterno.
Qualunque cosa scegli, ricorda due cose. Primo, i metadati non sono cifrati — la cifratura nasconde le parole, non la relazione. Secondo, verifica l'affermazione: preferisci client open source e una giurisdizione rispettosa della privacy, così che «non possiamo leggere la tua posta» sia qualcosa che puoi controllare invece di qualcosa che devi credere.
Per il lato archiviazione della stessa configurazione di privacy, vedi la nostra guida al cloud storage cifrato per sviluppatori, e per la questione più ampia di tenere i dati fuori dai servizi soggetti alla giurisdizione statunitense, il pilastro sulla sovranità dei dati.
