In questo articolo Indice dei contenuti 3 sezioni
Le email fanno parte della routine di chiunque, ma sono davvero private? La domanda è meno banale di quanto sembri. Che si usi Gmail, Outlook o Proton Mail, oppure un programma come Thunderbird o Microsoft Outlook, dietro ogni messaggio lavorano protocolli diversi: SMTP per l’invio e il passaggio tra server, IMAP e POP3 per consultare la posta in arrivo, HTTPS per le interfacce web. Le connessioni possono essere protette con TLS (Transport Layer Security), che cifra i dati in transito. Eppure la presenza della crittografia non vuol dire che solo mittente e destinatario possano leggere il contenuto, perché i messaggi attraversano infrastrutture di provider differenti e vengono elaborati e conservati su server che possono accedervi.
Il viaggio di un messaggio e i punti in cui può essere letto
Basta seguire una mail spedita da Gmail verso un indirizzo gestito da un altro fornitore per capire dove stanno i punti delicati. Semplificando, i passaggi sono cinque. Sul computer del mittente il testo resta normalmente in chiaro mentre viene scritto. Poi raggiunge il server del provider tramite HTTPS oppure SMTP con TLS, e lì può essere generalmente elaborato. A quel punto il provider interroga il DNS per individuare il server destinatario e tenta la consegna, di solito usando STARTTLS per proteggere il collegamento. Il server di arrivo riceve il messaggio, lo passa eventualmente ai filtri antispam e antivirus e lo archivia. Infine il destinatario lo apre via HTTPS, IMAP con TLS o altri protocolli protetti.
Il nodo sta tutto qui. TLS protegge la comunicazione tra le due estremità di una connessione, non il contenuto mentre viene trattato sui server. Un fornitore di posta potrebbe quindi avere un accesso tecnico ai messaggi, il che non significa che il personale li legga o che vengano sfruttati a fini commerciali. Per verificare il percorso basta guardare le intestazioni tecniche, gli header. In Gmail si apre la mail, si preme il pulsante con i tre puntini accanto a Rispondi e si sceglie Mostra originale. In Thunderbird si usa la combinazione CTRL+U. Le righe che iniziano con Received descrivono i passaggi e vanno lette dal basso verso l’alto. Diciture come ESMTPS e TLS13 indicano che il server dichiara di aver ricevuto il messaggio su una connessione SMTP protetta, anche se bisogna distinguere le righe inserite da server affidabili da quelle eventualmente falsificate da chi spedisce.
Perché STARTTLS può essere aggirato
Con OpenSSL, disponibile su Linux e installabile anche su Windows, si può interrogare un server SMTP senza inviare nulla. Dopo aver individuato i server di posta del dominio attraverso i record MX, il programma mostra i dettagli della sessione TLS, il certificato e l’algoritmo negoziato. Un risultato con TLSv1.3 e un codice di verifica del certificato pari a zero è un buon segnale, purché certificato e nome del server corrispondano. Se la connessione fallisce non è detto che il server sia insicuro, visto che la porta 25 potrebbe essere bloccata dalla rete o soggetta a restrizioni.
Il punto debole è un altro. Nel trasferimento tra server STARTTLS viene spesso usato in modalità opportunistica: il mittente prova ad attivare la cifratura ma può consegnare comunque il messaggio se il destinatario non la supporta. Siccome la prima parte dello scambio avviene prima dell’attivazione di TLS, un aggressore in grado di intercettare e modificare la comunicazione potrebbe cancellare la riga che annuncia STARTTLS. Il server mittente crederebbe così che l’altro non accetti connessioni cifrate e spedirebbe tutto in chiaro. È il cosiddetto attacco di downgrade.
MTA STS e DANE, due difese con un limite preciso
Per evitare questo scenario esistono due soluzioni. La prima è MTA STS (Mail Transfer Agent Strict Transport Security), descritta nell’RFC 8461, che consente al dominio ricevente di chiedere agli altri server di inviare messaggi solo attraverso connessioni cifrate e verificate. Se un mittente compatibile non riesce a stabilire una connessione TLS sicura deve rinviare la consegna. Interrogando il DNS del dominio si può controllare se la configurazione è presente, e la voce più interessante è mode enforce, che impone ai server compatibili connessioni correttamente autenticate. La seconda è DANE (DNS Based Authentication of Named Entities), definita nell’RFC 7672, che sfrutta informazioni pubblicate nel DNS e protette da DNSSEC per verificare di parlare con il destinatario giusto.
Entrambi i meccanismi funzionano soltanto se anche il server mittente li supporta e li applica. Soprattutto proteggono il trasferimento, non il contenuto una volta arrivato. Quando la mail raggiunge il server di destinazione il provider di norma può accedervi, e per impedirlo serve la crittografia end to end, che protegge il messaggio prima ancora che venga spedito.
Fonte: TecnoAndroid