3 ms·
Well-run email clients and servers are in an OK state today regarding encryption, and the weaknesses that exist are more related to adoption than technology. Ta
by jcrites 10y ago
Well-run email clients and servers are in an OK state today regarding encryption, and the weaknesses that exist are more related to adoption than technology. Take a typical office setup: your email client communicates over TLS with your central mail server (e.g. Exchange, Postfix) to retrieve or submit messages. This is true with webmail clients like Gmail and Outlook Web Access, as well as ones like Outlook/Mail.app/etc.
When sending or receiving email from other organizations, your mail server will communicate over TLS as well. Virtually all ISPs support TLS-protected SMTP today, and if you run your own server you can set it up easily enough. Google's Safer Email Transparency Report publishes statistics about the percent of encrypted email between Gmail and other top email ISPs [1]. TLS wasn't always widely supported in the past -- just as with web servers -- but any modern installation today will support TLS.
Modern email installations and usage are secure against passive surveillance as well as HTTPS. Where email is still weak is in its usage of opportunistic TLS (still common if not the default). An adversary capable of conducting a man-in-the-middle attack can force connections to fall back to plaintext, or can present a bogus self-signed certificate since many servers and clients do not expect a path-validated certificate.
There are defenses against those attacks, though. You can configure your SMTP server to require TLS, and to accept only path-validated TLS certificates from trusted certificate authorities. This will prevent an adversary from forcing your traffic to plaintext, and will prevent them from substituting a bogus self-signed certificate. With these protections in place, one can achieve a fairly good measure of security with basic email.
This is not to say that email is suitable in all circumstances. For high sensitivity use-cases one should consider attacks on infrastructure like the mail server: as we saw in this year's political campaigns, mail servers can be a trove of confidential information. One benefit of the GPG approach is that the mail server does not need to be trusted with the confidentiality of the communication, and so cannot compromise it.
[1] https://www.google.com/transparencyreport/saferemail/ https://www.google.com/transparencyreport/saferemail/ The systems that show up as plaintext in this report are largely older commercial bulk email sending systems; all consumer-oriented ISPs adopted TLS a while back.
- angry_octet 10y agoI would dispute your contention that 'most' ISPs support (opportunistic) TLS for SMTP. Looking at the email I receive, both at gmail and self hosted domains, almost no one will do TLS - only big internet companies like eBay. No clients that I'm aware of maintain a history of opportunistic TLS success. Maybe Let's Encrypt will change TLS adoption but I doubt it. It would need Google/Hotmail/Yahoo to increase the spam score for non-encrypted mail. But it's still way too complicated.
- caf 10y agoThere are defenses against those attacks, though. You can configure your SMTP server to require TLS, and to accept only path-validated TLS certificates from trusted certificate authorities. This will prevent an adversary from forcing your traffic to plaintext, and will prevent them from substituting a bogus self-signed certificate. With these protections in place, one can achieve a fairly good measure of security with basic email. This only works if you're also forcing DNSSEC: otherwise, the attacker can substitute their own MX in your DNS responses.