Can Someone Read My E-Mail?

Inbound mail is vulnerable as well. There are often multiple levels of relaying (including, of course, the firewall) before it reaches the end-user's mail server. From there, the user generally uses something like POP3 to download it to the PC.

UNIX users go through a similar dance, though in their case the mail is likely to be read by someone who has logged in remotely to the mail server, either via rlogin or via an X window.

The real point, though, is that the mail will sit on the disk of each of these machines for some amount of time. That makes it easy pickings for anyone with privileged access to those machines.

Even the originating and receiving users machines are vulnerable, if not directly then via their network usage. For example, if the user relies on a network file server, that machine has the actual mail. Similarly, if a computer is backed up over the network, the backup server has copies. Are all of these machines secure?

First, of course, an attacker can pick up your password. This is old technology, and works very well. And bear in mind that many POP3 clients transmit your password every time they check for mail.

For UNIX users, IP spoofing is an easy way to gain access to the server. Failing that, it's often easy to connect to a user's X server and read keystrokes and screen images that way.

Let's start with what we've already talked about. If you're logging in to a remote machine to read your mail, you're still toast, because the mail will traverse the net after you've decrypted it. For that matter, the password you use to unlock your secret key will traverse the net, too. Or maybe the attacker will just pick up your keystrokes from your X server.

Moving on from there, consider the lovely things that can be done with tailored viruses. There have also been a number of bugs in Web browsers that permitted access to arbitrary files on the machine.

• Start with a good encryption package (see below). If the basic technology is no good, you're just wasting your time and money.
• Use it properly, don't take shortcuts, and follow the instructions. They're there for a reason.
• Encrypt and decrypt mail only on secure machines. The level of security depends on how sensitive the information is (and on how paranoid you are). My own laptop is probably more secure than the corporate firewalls -- but I'm a paranoid by profession.

  If you don't know how to secure your machine, get help. The general rule, though, is to ensure that as few services as possible are running, even if it means sacrificing some convenience.

• If you're connecting to a secure machine over a network, it's probably not a secure machine... There are exceptions, of course, especially if you use a cryptographically protected channel to log in.
• Your secure machine should never extend trust to an insecure machine. For example, never run programs from an insecure source, either by downloading them or by executing them from a file server. Similarly, don't permit X server connections from insecure machines, even if they travel over an encrypted channel.
• Don't store cleartext copies of sensitive mail. Either save only the encrypted form, or use an encrypting file system. There are packages available for both UNIX and Windows systems.
• Keep the machine physically secure. Physical access wins -- always.
• Last, don't make the machine so secure that it's unusable. If it is, your mail will be less secure, because you'll never use the encryption package.

• Start with a decent key size. 40-bit systems are good enough to keep out 6th graders. They might keep out high school students; they won't protect you from anyone with access to a LAN-full of machines. 56-bit DES systems are at best marginal. They'll keep out the casual hackers, but are weak against an adversary who can spend just a few hundred thousand dollars. Recently this was demonstrated quite publicly. Clearly, the list of groups that can afford such devices includes most medium-sized companies. And I'd bet that most major governments already have DES-cracking abilities in-house.
• Use a well-known cipher. Proprietary algorithms are generally worthless. Eric Thompson, CEO of AccessData -- a private-sector cryptanalysis firm! -- estimates that the average home-grown cipher takes about a day to cryptanalyze. DES is good -- or would be, with a longer key length; use triple DES instead. RC4 (with a decent key size) is well-regarded, as are IDEA and RC5 (again, with a decent key size). (Note, though, that some of these are patented.) The best choice is the Advanced Encryption Standard (AES); it's fast, free, and strong enough for classified traffic.
• Make sure it's configured properly (i.e., disable any use of 40-bit keys).
• Buy from a reputable firm that understands security. There are lots of little things to get right, like making sure a copy of the key doesn't get written out to the swap area.

If you do use certificates, make sure you trust the issuer. You can buy your own certificate-issuing program, but the machine it runs on has to be very secure; if it gets compromised, your entire secure e-mail infrastructure may be compromised.

I should add that with proper software structuring techniques, a large program may be able to provide adequate protection of the security-sensitive pieces. But that's hard, and requires a degree of self-discipline that's relatively rare. Stand-alone programs, though sometimes less convenient to use, are much more likely to be secure.

There is one class of secure email program to avoid at all costs. These are intended for use when you wish to send email to someone who doesn't have a decryption program. These encryptors package up the ciphertext in a self-extracting executable and send it to the recipient.

Now -- consider the security model from the recipient's perspective. At a time when they think that someone might be reading their email, they're supposed to (a) run a program sent to them in an unauthenticated fashion, and (b) type a secret into this program of unknown origin. And this is quite apart from the more general class of bad things that can happen from trusting emailed executables.

Regrettably, several otherwise-responsible vendors have introduced such products. Don't just trust the brand name; some ideas are stupid, no matter who sells them.