E-mail

When you visit a web site with your web browser, you are creating a connection between your computer and a distant server such as your bank, an online retailer, or whatever. This connection may or may not be encrypted. If it is encrypted, then you can be sure that no one else will be able to peek at your messages.

With e-mail, however, the complexity basically doubles. To send an e-mail message, you first send the message to your e-mail provider, and then your provider attempts to send the message to the recipient. This allows the service to “store and forward” the message. If the recipient is not immediately available (i.e., “online”), then the message can be saved for future transmission. Even if the recipient is currently available, the nature of the e-mail system is to keep a copy of the message on the server until the user explicitly deletes it. (See Figure 8-1.)

Note, however, that the recipient may use an entirely different e-mail service. For example, if [email protected] sends an e-mail to [email protected], then both Google and Yahoo will have copies of that message on their servers—one copy for Alice and another for Bob. (See Figure 8-2.) If Alice deletes her copy, Bob may still have his copy, or vice versa. (Of course, even if both Alice and Bob delete their copies of this message, Google and Yahoo may well still keep their copies on the server for some period of time.)

When we talked about encryption used for surfing the Web, all of the communications were point-to-point and short-lived. With e-mail, the message is often encrypted only in transit (the arrows in the diagram). The messages themselves are rarely encrypted, meaning that anyone with access to the computers or servers could potentially read the e-mails. E-mails are really more like postcards than sealed letters because anyone involved in transporting the message can read it. Also, while the connection between Alice and Google’s e-mail server may be encrypted, she has no way to know or control whether the link between Google’s server and Yahoo’s server is encrypted or whether the link between Yahoo’s server and Bob’s computer is encrypted. In fact, until recently, many of these server-to-server links were known to be unencrypted.

So, what can we do about this? The best answer is to encrypt the e-mail message itself, before it ever leaves Alice’s computer. Bob would then decrypt it when it arrives, and no one in between would be able to see the contents. Unfortunately, this is not easy for the average person to do, at least not yet. Google and other mainstream e-mail service providers are working hard on providing solutions that will work without a lot of user interaction, but as of the writing of this book, they are not yet available. The process involves generating a public/private key pair using a passphrase, publishing these keys to one or more public key servers, and…I’ve already given up. Regular people will never do this. We need something that just works. It may be something entirely new, relegating e-mail to an old technology you’ll tell your grandkids about. E-mail just wasn’t built for end-to-end encryption. Nevertheless, there are some viable options now, and I’ll tell you about them at the end of this chapter.

Text Messaging

Short Message Service (SMS), or texting, came around with the advent of mobile phones. It’s still the lower common denominator today for mobile messaging—all cell phones and cellular service providers support this technology. Texting is similar to sending an e-mail. It supports the store-and-forward function, meaning that the intended recipient doesn’t need to be online to get your message—you can send it whenever you want, and whenever they turn on their phone, the message will be delivered. Also, the phone companies have managed to work out the technical stuff to allow someone on Verizon to send text messages to someone using AT&T or T-Mobile. Apple has even integrated SMS with its instant message system (Messages or iMessage) so that you can use Apple’s proprietary system if all parties are using an Apple product (in which case the messages are blue) or fall back to regular text messaging otherwise (where message bubbles will be green).

Instant messaging (IM) has been around for about as long as e-mail, believe it or not. They both date back to the early 1960s. IM is similar to e-mail in terms of the communications pathways shown in the diagrams for e-mail, but there are two main differences. First, there’s usually no store-and-forward ability. Second, instant messaging is mostly proprietary, so there is usually only one service provider involved. That is, if you’re using Google’s IM service, you generally can’t communicate with someone using Yahoo Messenger or AOL’s AIM service.

This is similar to the newer, mobile-oriented messenger apps: WhatsApp, Facebook Messenger, Telegram, WeChat, Discord, and so on. To chat with others, all users must have the same app installed. Unlike older instant messaging , most modern messenger apps will allow messages to be stored and forwarded if the intended recipient isn’t currently online.

Spam and Spoofed Messages

Junk e-mails and messages—usually unsolicited advertisements—are referred to generally as spam. Many of our most-used messaging platforms are open by default. That is, if you know someone’s e-mail address, messaging handle, or cell number, you can send them a message—no permission required. Some messaging systems have implemented a check mechanism whereby you have to first allow the other person to “follow” or “friend” you before they can send you a message; however, this support isn’t ubiquitous.

If you’re lucky, the spammers will only send you advertisements. However, spam is also a favored delivery mechanism for malware—either with links to bad web sites or with malicious code embedded in attachments. These links and attachments can be sent using e-mail, text messages, and messenger apps.

It’s important to realize that it’s easy for the sender of a message to be spoofed. That is, just because the “from” on the e-mail or text message is someone or some company you know and trust, you can’t assume that it’s really coming from them. Also, e-mail accounts are often hacked, so even if a message truly is from where it says it’s from, you still have to be very wary of any links or attachments given to you. While antivirus and other safety utilities do an okay job of blocking these things, you can’t assume that they are 100 percent effective.

You also need to realize that you can’t trust the text of a link. Just because the link says http://google.com/ doesn’t mean that that’s really what the link is pointing to. Sometimes if you hover your mouse pointer over the link, your browser or e-mail app will show you the actual link. In fact, if you have the eBook copy of this book and you hover over that link, you’ll see that it’s actually fake (Figure 8-3).

Sometimes the bad guys will try to trick you with web sites that are slightly misspelled, often in a way that is hard to catch like out1ook.com or tvvitter.com.

It gets worse. There’s a web technology called Punycode that allows for encoding all sorts of fancy foreign character sets , which is nice. But some of these non-English characters look just like their English counterparts. Bad guys can register web domain names using these characters, and you won’t be able to tell the difference no matter how closely you look. Check the example in Figure 8-4.

The top value is what you would normally see, but the unencoded version (the real web site) is what you see at the bottom. While this appears to be the English alphabet characters a-p-p-l-e, the web address here is actually using characters from the Cyrillic alphabet that happen to look just like a-p-p-l-e in the font used by Chrome and Firefox browsers.

Thankfully, web browser password manager plugins like LastPass will not be fooled by either of these tricks. If you go to a web site that should be familiar but LastPass isn’t offering to fill in your username and password, then you might not be looking at the web site you think you are.

Many web links today just immediately redirect you to another web site, so you can’t be certain that what you see is what you’ll get. There are link-shortening services that will take long, obnoxious web addresses and shorten them to something much easier to type and/or remember. These services perform a redirect from the short link to the real destination. So, for many reasons, you simply cannot judge a link by its text.

Finally, some images and links that come in e-mails can be used to track your movements on the Web and will also help spammers to mark you as a viable target. This is why many e-mail clients will refuse to load the images contained in an e-mail until you say it’s okay. For example, a spammer may get a list of a million e-mail addresses from someone who hacked into some databases. The spammer has no way of knowing whether all of these addresses are real and still active. They will also not know if a particular e-mail was able to get through all the various spam filters that are between them and the recipient. But if they put an image in that e-mail with a unique identifier and your e-mail client downloads that image from the bad guy’s server, then they will immediately know that the e-mail address works and that it got through to you... in which case you should expect to receive more junk mail.

Many solutions have been proposed for stopping spam, but because the Internet is so driven by marketing and advertising, the key players have been loath to adopt them. It comes down to this: who gets to determine what’s junk? We’ve had the same struggle with regular junk mail delivered by the postal service. The postal office makes a lot of money delivering those ad flyers to you. However, the risks of malware I believe will eventually drive the industry to offer some sort of solution.

One option would be to charge a small amount of money to transmit more than, say, 100 e-mails in a 1-hour period or maybe 500 per day—something that would not affect most people but would cause spammers some grief. Right now, e-mail is essentially free, which leaves it open for abuse. The problem here is that this could hurt small, legitimate businesses and still allow massive, wealthy corporations to continue sending gobs of unwanted e-mails.

The most draconian option would probably be moving to a whitelist system where you cannot send e-mail to someone unless they first approve you as a sender. This could be automated to a certain degree. When you first e-mail someone, you will get a canned response from the service provider saying something like “I only accept e-mail from people I know. Please contact me by some other mechanism first or answer these few questions to prove you know me.” Spammers deal with millions of e-mails, so they wouldn’t have time to bother with this. This would still allow legitimate companies with which you actually have some relationship to contact you. The process of registering on their web site could automatically add them to your whitelist of approved senders. My gut tells me that this is where we’ll end up, unless we come up with a completely new scheme for sending electronic messages .

Until then, we have limited methods of dealing with junk messages. We’ll cover those in the checklist.

“So How Do I Communicate Securely?”

Most of the time, you will probably be satisfied knowing that your e-mails and text messages are encrypted in transit, even if the message itself is not. You’ll need to realize that your e-mail and messaging service providers are almost surely scanning your messages so they can improve their marketing profiles on you. Most of this is automated (it’s not a human reading your stuff), but nevertheless, you’re trading your privacy to use these free services.

But there will come a time when something you want to send needs to be really private. Maybe you’re discussing something deeply personal, or maybe you’re just trying to send financial information to your tax preparer. Remember that copies of whatever you send will likely remain on the servers of your messaging provider, possibly even after both you and the recipient delete the messages.

So, how can you do this? You have at least two options (and to be super secure, you can do them both simultaneously). We’re talking about data at rest versus data in motion, that is, encrypting the content of the message versus encrypting the channel that the data will pass through. Think about it this way. You can put your money in a safe—that’s security at rest. If you want to then send that money across town, you could hire an armored car—that’s security in motion. If you want to be really secure, you would have the armored car transport the money in the safe—that’s using both mechanisms at once. If someone hijacks the armored car or follows it to its destination, they’d still have to break into the safe to get the money.

Let’s talk first about securing your messages as they traverse the Internet. As we’ve said, most modern messaging systems will encrypt your message as it travels but will not encrypt the message itself. There are some notable exceptions that offer end-to-end encryption . That is, the message contents are actually encrypted at the sender’s device and are capable of being decrypted only by the recipient’s device. These systems use a form of asymmetric encryption like we discussed earlier in the book—using a public key to encrypt the message and a private key to decrypt it. Apple’s iMessage service offers full end-to-end encryption, as do the Telegram and WhatsApp messenger.¹ There are secure e-mail services, as well, including a wonderful service called ProtonMail. Unfortunately, in all of these cases, you’ll need your intended recipient to use the same service.

One way around this is to separately encrypt the contents of your message, and then you can theoretically send it using any communications mechanism you want. This would be like driving your safe full of money across town in the back of your pickup truck. Everyone can see the safe—and may well assume that it contains something valuable—but the contents are perfectly secure, assuming you bought a decent safe.

So, how does one go about encrypting a message or a file? The simplest way is to zip the file or files using a compression utility. These utilities are usually used to shrink the size of a file and/or bundle several files together into a single file. You select the file or files and tell the utility to zip them up, resulting in a single output file that should be smaller than the original(s). In fact, the most common such utility creates a file ending in .zip.

But these zip utilities also often have the option of adding a password to the bundle, meaning that the recipient won’t be able to unzip the file without knowing the password. Adding the password encrypts the entire bundle.

If what you’re sending could be sent as a Portable Document Format (PDF) file, you can also usually create PDF files with passwords. So, if you’re sending a single file, you could export that file to PDF format and add a password to that file. (This may require opening “advanced” options when exporting the file.)

Of course, if you have the option, you could combine both techniques: encrypt the contents and send them using an encrypted communications mechanism. But at a bare minimum, you need to encrypt the contents itself. Remember that whatever you send could be saved on a server somewhere for a very long time, possibly unencrypted, just waiting to be found. Encrypting the file is more important than sending the file using an encrypted communications channel.

Summary

Checklist