After you have thought through your threat model and secured your accounts and devices, you are ready to delve into communicating privately and securely with your clients and others. If you guessed this means setting up encrypted email, you are wrong.
Email Is Not Private
Love it or hate it, email makes the world go round, and it’s probably the main way you communicate with your clients, opposing counsel, experts, and many other people in your personal and professional life. Let’s take a look at how email works, and gain a better understanding of how private these communications are.
Email is based on a set of technical standards, the most important of which is SMTP: the Simple Mail Transfer Protocol. While other forms of electronic mail existed earlier, internet email as we know it was born in the early 1980s, culminating in the publication of the SMTP standard, called RFC 821, in 1982. The SMTP standard provides the rules that email servers everywhere still work under today. Neither privacy nor encryption are mentioned even once in the RFC 821 document. Under the 1982 standard, every single bit of email data is transferred across networks in the clear. And, because of the internet’s decentralized nature, email can bounce around quite a bit before reaching your inbox. Any machine that receives that email, even in transit, presents the opportunity for someone to intercept and read it. While things are somewhat better today1, you should assume that all email you send can be intercepted.
If you want to make your emails private, you need to encrypt them. Encryption scrambles data so that only the sender and intended recipient can read it. Done properly—and doing it properly is hard—it can be practically unbreakable.
Email Encryption Sucks
It has been possible to encrypt email since at least 1991 when Phil Zimmermann created PGP, which stands for Pretty Good Privacy. PGP uses strong encryption and is technically robust. Unfortunately, usability is not its strong suit. PGP has always been cumbersome and relies on users being able to carefully manage and exchange pairs of cryptographic keys: one you share with the world, and one you keep private. In practice, bad usability held PGP back from widespread use, and even today, more than 25 years later, it’s used relatively little in the world beyond encryption activists, hackers, and security researchers—and even those people are giving up on PGP for email.
A new paper by researchers at the University of Washington, which focused on the email habits of lawyers and journalists, reiterates that “encrypted email tools have long faced profound usability challenges.” While the researchers evaluated new approaches to improving PGP’s usability, significant challenges remain—partly because the standards that email operates on were designed (largely) without encryption in mind.
The takeaway point is this: there is no good solution for encrypting email, so I’m not going to recommend one.
Use Signal for End-to-End Encrypted Messaging
If encrypting email is such a bother, what can you do? There are two practical options: give up and send unencrypted email, or use something that’s not email. In some cases, the consequences of unencrypted email being intercepted are minimal. But if you have a particularly sensitive matter or a client who you reasonably believe is under surveillance, then your threat model should treat that differently, and you should take additional measures to protect those communications. This is where non-email messaging systems come in.
Messaging apps have been all the rage. These include WhatsApp, Facebook Messenger, Snapchat, and Apple’s iMessage, which is built into every iPhone. Many of these apps feature encryption, though in some apps—like Facebook Messenger—it’s turned off by default. Why would a messaging app not use encryption? As the saying goes, if you’re not paying for it, you are the product. Your chat history may be helping companies like Facebook and Google figure out the best ads to show you. This is, obviously, not great for your client confidences, so don’t use these products for attorney–client communications.
Today’s best encrypted messaging app is Signal. Every message in Signal is end-to-end encrypted, which means that it is never sent or stored unencrypted. Even the servers that provide the Signal service can’t read messages. The company behind Signal also doesn’t keep meaningful amounts of user data. In the one publicly-disclosed instance in which Signal user data was subpoenaed, the resulting production was paltry: no name, no address, no email, no message content, not even message metadata—just timestamps for when the user account was created, and when the user last connected to a Signal server.
This is a night-and-day contrast to the data practices of other internet companies. This is good for your client confidences. Use Signal.
Signal is available for both iOS and Android mobile devices. A desktop app is also available for Mac and Windows. The desktop app is tied to the mobile app and is installed through a Chrome extension.
Share Files Securely and Privately with OnionShare and Tor
One thing you can’t do with Signal is send attachments (other than pictures), which may seem like a deal breaker. In many cases, it’s fine to use hosted services like Google Drive to share files with clients. However, all hosted services introduce intermediaries you don’t control. These intermediaries can be hacked, and if the government is part of your threat model, those services can also be—and often are—subpoenaed. The solution is peer-to-peer sharing: using your computer to host the files, and transferring them directly to the recipient, with no intermediaries.
One tool designed with this kind of privacy in mind is OnionShare. OnionShare is a desktop program for Windows, Mac, and Linux, which works in conjunction with the global Tor privacy network and the related Tor Browser software. While the sender needs both OnionShare and the Tor Browser, the recipient needs only the Tor Browser.
Here’s how to send a file using OnionShare. As the sender, you run both Tor and OnionShare. OnionShare connects to the Tor network and creates a hidden service: basically, an anonymous server program with a unique secret address that is only accessible via Tor. OnionShare gives you this secret address, which you first send to the recipient in a secure way, such as a Signal message. The recipient then runs Tor and plugs in the secret address as an URL. Their Tor browser connects to your OnionShare hidden service. This connection is routed through a series of machines all over the world and is encrypted so those machines or other eavesdroppers on the network can’t read it. The recipient sees a simple website with a download link. Once the file is downloaded, your OnionShare turns itself off automatically. This way, even if the secret address were somehow intercepted, it wouldn’t do an attacker any good because the sender would no longer be sharing the files.
Tor itself is relatively stable, but OnionShare is experimental pre-release software, and has some known bugs. Before you use it, make sure you understand what it does and doesn’t protect against. This is described in detail in its Security Design Document.
Tor and OnionShare aren’t hard to use, but they are harder than dragging a file into an email and clicking send. In most cases, your threat model will probably not require you to use these tools, but they’re good to have available for extra-sensitive cases.
You Can Still Do Something About Email
Thankfully, all is not completely lost when it comes to email encryption. Over the years, SMTP has been extended to include an encryption method called TLS—very similar to what’s used to encrypt traffic between your browser and many websites. If your SMTP server and the destination SMTP server both support TLS, then your email should be encrypted as it transits the internet.
While the internet’s original design was all about decentralization—so the network would withstand losing nodes in a nuclear attack—in practice, most of today’s email traffic is concentrated in a handful of large service providers like Google and Microsoft. Because most of these big players do support TLS, the majority of the email between them is encrypted. For example, today, over 80% of Gmail’s incoming and outgoing email traffic is encrypted in transit.
Make sure that your email server supports TLS. If you use a major cloud email provider like Google or Microsoft’s Office 365, you’re all set. It’s easy to check any email address with the website CheckTLS.com.
A few of things to remember about TLS:
- Don’t rely on TLS to keep all your email private. It can’t.
- TLS only protects email when it’s in transit—not at rest. Once your email reaches its destination, the server it lands on can read it in the clear. That’s why Gmail’s search works. If this isn’t okay under your threat model, use an end-to-end encrypted tool like Signal instead.
- Both the source and destination servers must support TLS. If you’re sending to a domain that doesn’t support TLS, then your email will go across the network in the clear.
Nag Your Clients
It’s a cliche, but in information security, a chain is only as strong as its weakest link. Even if you do everything right, your client could still screw everything up by using “123456” as his or her email password. (There’s about a 17% chance of this, by the way.) So go the extra mile and nag your clients about their own security, and insist on using secure tools like Signal when you think it’s appropriate. Your clients just might be surprisingly appreciative of your attention to detail and privacy.
See “You Can Still Do Something About Email” below ↩