Tuttavia, per quanto ne so, quando si tratta di comunicazioni da server di posta a server di posta, la maggior parte delle e-mail viene ancora trasferita in testo semplice e non crittografata, rendendo possibile a chiunque sulla rete di leggere il proprio contenuto.
Corretta. SMTP, come HTTP, è un testo normale per impostazione predefinita.
Oggigiorno molti server di posta supportano TLS (precedentemente noto come SSL) per SMTP. (Questo include Gmail.) Tuttavia, presenta gli stessi problemi di HTTP [S]: i certificati emessi da note autorità di certificazione costano denaro e quelli autofirmati sono privi di valore 1 per la protezione dagli attacchi MitM . Se il tuo server di posta esegue una rigorosa convalida del certificato del destinatario (come fanno i browser Web), potrebbe non riuscire a recapitare i messaggi ai server che utilizzano certificati autofirmati o CA interni. In caso contrario , non può essere sicuro che stia parlando con il server giusto e non con un impostore .
Inoltre, TLS è un'aggiunta relativamente recente a SMTP, quindi anche quando il server di posta del destinatario supporta TLS, il mittente potrebbe non esserlo o potrebbe essere disabilitato per impostazione predefinita.
1 (A meno che il server mittente non supporti DANE (TLSA) e l'amministratore del server ricevente si preoccupi di pubblicare i record TLSA in DNS. Questo è raramente fatto e in qualche modo noioso.)
Esistono tecnologie che offrono all'utente garanzie che le sue e-mail vengano inviate in modo sicuro da un capo all'altro?
Due standard di sicurezza e-mail più comuni:
OpenPGP , basato su web di fiducia e gratuito da usare. L'implementazione open source è GnuPG ( per Windows , per Thunderbird ) e il PGP originale si è evoluto nel PGP Desktop commerciale .
Per i client di posta elettronica basati sul Web, FireGPG è una possibilità - dannazione
S / MIME , basato sull'infrastruttura X.509. Implementato dalla maggior parte dei client desktop (inclusi Outlook, Thunderbird, Mail.app). Tuttavia, relativamente impopolare a causa della stessa struttura basata sull'autorità di TLS / SSL: i certificati firmati costano denaro e quelli autofirmati non possono essere validati in modo affidabile.
In entrambi i casi, la crittografia richiede che il destinatario stia già utilizzando il sistema e abbia generato / ottenuto una coppia di chiavi. (Per la firma , viene utilizzata la coppia di chiavi del mittente . La prassi normale consiste nel firmare e crittografare i messaggi.)
Perché non far sapere all'utente quando la crittografia non è supportata e fargli scegliere se desidera che la sua e-mail sia ancora recapitata?
Di solito i messaggi inviati vengono messi in coda e né l'utente né l'MTA possono sapere se l'hop successivo supporta TLS o meno - fino a quando non viene inviato il messaggio , a quel punto non esiste un modo affidabile per chiedere conferma all'utente. (Possono essere AFK, offline, addormentati o uno script / programma. Se ho inviato il messaggio, voglio che venga recapitato il più presto possibile.)
Inoltre, con SMTP non sai mai se l'hop successivo è definitivo o se inoltrerà la posta altrove. Non è raro che un MX di backup si trovi su una rete completamente diversa.
Perciò. la sicurezza end-to-end è possibile solo quando entrambe le parti utilizzano OpenPGP o S / MIME.