The risk of email interception

| 3 Comments
Anyone who does email knows that it is really easy to intercept in-flight. Unless TLS is in use the messages are transmitted in plain text, and the SMTP protocol is designed around the assumption that untrusted 3rd parties may handle the messages between source and destination (a holdover from the UUCP days as it happens). The appliance and cloud anti-spam industries are designed around this very capability.

But how much of a risk is illicit interception? Or worse, monitoring? Everyone knows you don't send passwords or credit-card information in email, but we also send password reset messages in email. Some web-sites still send your password when asked for a 'reminder', so clearly some reset-system designers consider email secure-enough. Or maybe it's just convenience trumping security again.

To figure out how much of a risk it is we need to know 2 things:
  1. How can email be intercepted?
  2. How likely these methods are to be used?
Interception can be accomplished two ways:
  1. Catch the messages in-flight by way of a sniffer.
  2. Catch the messages in the mail-spools of the mailers handling the message.
There is another vector that is even more damaging, though. Catching the message in the final mailbox. That isn't interception, it's something else, but it really impacts the security of email so I'll be including it. Under the fold.
Sniffing messages in-flight

By far the easiest method for this is to sniff for SMTP transactions over a wireless network. Those transactions will have to be unencrypted, which is still pretty common these days, but they can still be readily captured. The same goes for mail access methods as well, this would be IMAP, POP3, or WebMail, with the added bonus of probably getting the login credentials as well.

Also on Wireless networks you get the option of ARP-poisoning and evil gateways. You may think you're talking SMTP-TLS to your mail host, but what you don't know is that your transaction is being seamlessly proxied by an Evil Gateway at the next table. Authentication and encryption works as normal (maybe... if the proxy TLS certificate is self-signed the mail client should scream. But maybe the mail-host always throws that so it's a well known ignored message), but the entire conversation is seen in the clear by the Evil Gateway. The same can hold true for SSLified POP and IMAP.

One step down the line and you get into the realm of Corporate Security. Most organizations are justifiably paranoid about outbound SMTP transactions these days, spam-botnets ruin everyone's fun, so the likelihood of that transaction being witnessed by Corporate is pretty high.

Another step down and you get to the ISP. The ISP may do its own monitoring of messages for spamminess, but generally not. An employee gone over to the dark side may indeed sniff SMTP traffic for resellable goodies, but the ability of non-employees to do this is very significantly curtailed. Much more likely is some form of Governmental monitoring.

On the backbone, the only monitoring going on is going to be Governmental. Terrorists ruin everyone's fun.

When it comes to sniffing as a way of illegally intercepting email, the origination point is the most likely area. Everything else is more likely to be authorized, even if it is unwanted.

Monitoring the mail-spool

Instead of watching the packets on the wire, watch files in the spool-directory. Unlike SMTP-TLS, these files are generally not encrypted in any way. In fact, this method may be the only way to catch messages sent with end to end TLS. Unfortunately for the evil people, this method is the hardest to put in place.

Putting this in place generally requires hacking mail servers, and doing so quietly. As it happens, anti-virus/anti-spam systems do exactly this, but legitimately, so most systems provide hooks for doing this. The trick is getting into the system in the first place.

If you are a Government with a warrant, access can be gained pretty simply. However, this is authorized monitoring not illicit.

Logging in to the mailbox

The person doing the sniffing in the coffee shop may not care about your email, they may just want the username/password pairs that they can then sell on the black market for real money. Spammers are always on the lookout for webmail logins to mail systems considered trusted (such as the WWU Student email system) since mail from such systems will pass IP reputation checks and is more likely to be seen by the recipient. Therefore, WebMail logins are considered valuable.

Also, WebMail logins are great for identity thieves. Once access to a mailbox is gained, it is easy to sift through it looking for goodies. Also, a list of ecommerce sites visited by the owner is very easy to get, which in turn creates a target list. Go to a site known for storing credit card information and displaying it in the clear, go through the password-reset process to gain access (email addresses are VERY common 'usernames' these days, and they control the mailbox now) and suck down the CC info.

What's insidious about this is that the Owner may not even notice that they've had a password change on such sites. If they're not using a password remembering program, the sudden inability to log in may be chalked up to old age, and they just reset it back to a password they know.

Risk analysis

In the end, the biggest risk is not interception of email, but interception of login credentials. The evil person sniffing the coffee-shop wireless may oversee a received password-reset email, but in order to see that they also probably caught the POP3/IMAP4 login, which is a much more valuable property. Given password re-use, it can even chain to access to other interesting places. Phishing for email logins is something I deal with on a weekly basis.

Monitoring by Corporate or Governments is harder to avoid, but they're more concerned with preventing and catching illegal activity than causing it.

Monitoring of email in flight is much more likely to be performed by entities (corporate or Governmental) that are concerned with what the contents might contain and what it says about the sender. Unless there is an on-going investigation, they don't care about usernames and passwords. The criminal element is more interested in username/password pairs as they can then bootstrap them to more profitable things.

Mitigating these risks is accomplished through a well known list:
  • Do not use self-signed certificates for anything at all. Just don't do it.
  • Do not permit unencrypted authentication to the mail system over any protocol. SMTP, POP, IMAP, and WebMail all need to require encryption.
    • This means paying for SSL certificates from trusted authorities, not minting your own from your own CA. End users can be trained to import certificates, but enough of them will just learn to click past the WARNING! screen, which will leave them vulnerable to man-in-the-middle attacks.
    • If certain Mobile devices can't handle encryption for some reason, learn to say no.
  • Turn on SMTP-TLS support for your mailers. This allows email to be sent encrypted between mailers, which will reduce (but not prevent) even Governmental monitoring.
    • Once again, having an SSL certificate that chains to a public authority will greatly increase the ability of mail to be sent encrypted. Some mailers won't talk TLS to mailers that don't chain somewhere trusted.
  • In your WebMail interface, display a login history and date of last password change.
  • If possible, communicate that a password change has happened through some out-of-band method. SMS can be used for this, if allowed.
Unfortunately, preventing successful Phishing is hard. Social engineering is always tricky to mitigate.

Taking short-cuts with your mail system (self-signed certificates, allowing unencrypted logins for mobile devices) is a great way to expose this critical communication medium to attack. With email being bundled with ever more services these days, a GMail account allows access to Google Docs for instance, that credential is one that needs to be treated very seriously and protected accordingly. As a mail user, you can chose to only use mail systems that do the above. If you're stuck using a corporate email system that doesn't do at least the first two points above, start pushing hard to have it done. The internet will be better for it.

3 Comments

You didn't mention S/MIME or PGP style encryption, but that's really the only sure-fire way to protect email contents (if not the envelope itself) all the way from client to client. I realize that client encryption methods are extremely rare outside of the hardcore techie community, but I don't see that as a reason to not push users to give it a try...

You raise two valid points. I agree, it would be tough to convince more than a handful of people to encrypt. However, for those that really *need* private communications (HR, Finance, etc.), then it's not a bad option.