Update: Since this article was published, GPGTools released version 2018.2 which appears to successfully mitigate the OpenPGP EFAIL attack for macOS High Sierra users. If you use macOS High Sierra, Apple Mail, and GPGTools, it should be safe to use PGP again if you update to the latest version of everything. If you use an older version of macOS, GPGTools is still vulnerable.
It’s been nearly two weeks since a group of European researchers published a paper describing “EFAIL,” a set of critical software vulnerabilities that allow encrypted email messages to be stolen from within the inbox. And developers of email clients and encryption plug-ins are still scrambling to come up with a permanent fix.
Apple Mail is the email client that comes free with every Mac computer, and an open source project called GPGTools allows Apple Mail to smoothly encrypt and decrypt messages using the 23-year-old PGP standard. The day the EFAIL paper was published, GPGTools instructed users to workaround EFAIL by changing a setting in Apple Mail to disable loading remote content:
Similarly, the creator of PGP, Phil Zimmermann, co-signed a blog post Thursday stating that EFAIL was “easy to mitigate” by disabling the loading of remote content in GPGTools.
But even if you follow this advice and disable remote content, Apple Mail and GPGTools are still vulnerable to EFAIL. I developed a proof-of-concept exploit that works against Apple Mail and GPGTools even when remote-content loading is disabled (German security researcher Hanno Böck also deserves much of the credit for this exploit — more on that below). I have reported the vulnerability to the GPGTools developers, and they are actively working on an update that they plan on releasing soon.
Here is a short video that demonstrates how dangerous this exploit could be:
If you’re an Apple Mail user who relies on PGP-encrypted email, and completely disabling PGP for the time being, like the Electronic Frontier Foundation, or EFF, recommends, isn’t an option for you, then your best course of action is to temporarily stop using Apple Mail and switch to Thunderbird, at least until GPGTools releases an update that fixes this issue.
Thunderbird is an open source email client that works on Macs, and the latest version of the Enigmail plug-in, which adds PGP support to Thunderbird, successfully mitigates the EFAIL attack, at least as far as is publicly known. If you’re using Thunderbird, you should also configure it to only view emails in plain-text format instead of HTML format. Disabling HTML in your email will will prevent most, or maybe all, future variants of this attack from working against you. You can do this by clicking View > Message Body As > Plain Text.
Unfortunately, Apple Mail does not have an option to disable viewing HTML emails.
In a nutshell, the EFAIL attack works like this: First, the attacker needs a copy of a message that’s encrypted to your public key. They could get this by hacking your email account, hacking your email server, compelling your email provider to hand it over with a warrant, intercepting it while spying on the internet, or other ways. PGP was specifically designed to protect against this — the promise of PGP is that even attackers with copies of your encrypted messages can’t decrypt them, only you can. When you receive an email that’s encrypted to your public key, your email client automatically uses your secret key to decrypt it so that you can read it. The EFAIL researchers discovered that they could craft a special email that secretly includes a stolen encrypted message within it, and then send it to you. When you receive the malicious email, your email client uses your secret key to automatically decrypt the pilfered message within the malicious email, and then sends a decrypted copy of the stolen message back to the attacker — for example, through a web request to load an image into the email.
“One click means you lose the very thing that PGP is supposed to protect.”
On May 14, the research team behind EFAIL published its paper. At that point, both Thunderbird with Enigmail and Apple Mail with GPGTools were vulnerable for users who were using the default settings.
That day, EFF published a blog post stating that the proof-of-concept exploit provided in the EFAIL paper “is only one implementation of this new type of attack, and variants may follow in the coming days,” and that “EFF is advising PGP users to pause in their use of the tool and seek other modes of secure end-to-end communication for now.” This advice — to uninstall PGP software until the situation is resolved — caused a controversy in the digital security world. Nonprofits in this space pushed back against EFF’s stance, like in this blog post from Privacy International and in this blog post from the American Civil Liberties Union. (In my opinion, both sides make good points, but more on that below. Also, I worked previously at EFF.)
Also on May 14, GPGTools tweeted instructions to work around the vulnerability: Disable loading remote content in emails. While this at first appeared to mitigate the problem, in reality, it didn’t. Like EFF predicted, GPGTools is still vulnerable to a variant of the EFAIL exploit, as my exploit demonstrates.
On May 16, Enigmail released an update that mitigated the EFAIL vulnerability — only it turns out, this mitigation didn’t work either. The following day, Böck, the German security researcher, tweeted that he found a “trivial bypass” in Enigmail’s new version, and he disclosed his bypass to the Enigmail developers so that they could fix it.
so... about efail. the latest Enigmail version contains a few Mitigations. They don't work. I found a trivial bypass. So to be clear: efail is still exploitable with latest Enigmail+Thunderbird and default settings.— hanno (@hanno) May 17, 2018
On May 21, Enigmail released yet another update to mitigate EFAIL. On Twitter, Böck confirmed that this new version actually prevents his exploit from working, adding that “I’m still not happy with the mitigations” and “disabling HTML mail is still a good idea.”
I personally know many journalists, free software developers, and activists around the world that rely on Apple Mail and GPGTools for encrypted email on a daily basis. So, I decided to write my own EFAIL exploit against Apple Mail. My initial exploit, which I announced on May 15, worked only if the user clicked the “Load Remote Content” button.
I implemented a simple #efail exploit for Apple Mail, which is vulnerable with its default settings. The mitigation works but is brittle. Until @GPGTools fixes this for real (they haven't released an update yet), never click "Load Remote Content" https://t.co/DY5ZtbkU6e— Micah Lee (@micahflee) May 16, 2018
Later, I became curious if Böck’s technique to bypass Enigmail’s initial EFAIL fix would work against Apple Mail and GPGTools, even with the suggested mitigations. After Enigmail released a patch, he agreed to privately share his technique with me.
It took me about 10 minutes to modify my initial exploit to work against Apple Mail and GPGTools as well, even when remote-content loading is disabled. As soon as I confirmed that my exploit worked, and recorded a little video showing it working, I disclosed this vulnerability to the GPGTools developers in order to make sure that whatever update they’re working on will block this variant of the attack as well. (Since creating the video, I have discovered a separate simple variant of the EFAIL attack that also works against GPGTools with remote content disabled.)
Hopefully GPGTools will release an update soon that fixes this issue. But because the details of the EFAIL vulnerabilities have been public for weeks, and because this and related exploits are relatively simple, and it’s likely that others have already discovered them, we decided that it’s in the public interest to warn Apple Mail PGP users sooner rather than later that there is currently no available mitigation to EFAIL. This is especially true when some security experts are falsely claiming that disabling remote content in Apple Mail will mitigate the problem, such as in the statement co-signed by Zimmermann, which was also co-signed by the founders of Enigmail, the encrypted email service ProtonMail, and Mailvelope, a browser add-on for encrypted webmail.
Despite having several months of lead time, the Enigmail and GPGTools projects failed to fix the EFAIL vulnerabilities.
One difference between this EFAIL variant and the proof-of-concept that the researchers published in their paper is that the user needs to click something to get exploited. “I think a lot of non-expert users do things like click on links they receive from trusted senders,” said Matthew Green, a cryptography professor at Johns Hopkins University. “They should feel comfortable and safe doing that, and they shouldn’t have to worry about losing their data to an attacker.” He expects that people could find more EFAIL exploits in email clients.
This EFAIL variant is “pretty serious in the sense that one click means you lose the very thing that PGP is supposed to protect,” EFF International Director Danny O’Brien said, “and there’s nothing you can do to defend against it — apart from remembering never to click anything in email ever again.”
Even with Enigmail updates, EFF isn’t confident that PGP is safe to rely on again yet, but it’s getting safer. “I want to stress that everybody in the PGP ecosystem has been working on this problem, and every day exploiting EFAIL gets harder,” O’Brien said. “Two weeks ago, you didn’t need to click for EFAIL to work. With the latest updates to Enigmail and Thunderbird, security researchers like Hanno [Böck] can still trigger it — but it takes more social engineering than just a single click.” He added that donating to projects like GPGTools and Enigmail would help, too, because “these people are almost all volunteers.”
Before I go into more details about EFAIL and how it affects the PGP ecosystem, I want to take a moment to discuss S/MIME, a different encrypted email standard that is far more vulnerable to attacks described in the EFAIL paper than PGP is, and that also presents more obstacles to mitigation.
The real news here is probably about S/MIME, which is actually used in corporate e-mail settings. Attacking and modifying encrypted email stored on servers could actually happen, so this is a big deal. 4/— Matthew Green (@matthew_d_green) May 14, 2018
Unlike PGP, which is decentralized and uses a model called “web of trust,” where users deal with key management and identity verification themselves, making PGP notoriously confusing, S/MIME uses “certificate authorities,” where an organization (like your employer) centrally manages identity verification for its users, making S/MIME ideal for deploying encrypted email to large organizations.
S/MIME is widely deployed in banks, major corporations, and government agencies around the world, including the U.S. Department of Defense. It’s built into all major email clients, including Outlook and the default email apps on macOS, iOS, and Android, without requiring a plug-in. At the time of writing, as far as I can tell, no email clients have released an update that mitigates EFAIL for S/MIME, leaving all S/MIME users currently vulnerable to these attacks.
The reason I’m focusing primarily on PGP instead of S/MIME is because it’s what I, and the communities I work with, having been using for years.
EFAIL has demonstrated how bad the encrypted email ecosystem is at responding to vulnerabilities in a timely matter. According to this timeline compiled by security researcher Thomas Ptacek, Enigmail was first notified about the EFAIL research in November 2017, and GPGTools was first notified in February 2018. Yet by May 14, when the researchers published their paper, both of these projects were still vulnerable.
Compare this to recent pair of vulnerabilities found in Signal Desktop earlier this month: Researchers discovered a remote code execution — hacker-speak for “very bad” — vulnerability in Signal Desktop on May 10, and they disclosed it to the developers on May 11. Later that same day, the Signal developers fixed the problem and released an update. But their fix wasn’t complete; on May 14 researchers discovered a second way of exploiting the vulnerability. An hour later, they disclosed it to the developers, and less than two hours after that, a new Signal Desktop update was released which finally solved the problem. Signal Desktop automatically updates itself, so nearly all users should have gotten the updates the day they were released.
Despite having several months of lead time, the Enigmail and GPGTools projects failed to fix the EFAIL vulnerabilities before the paper was made public. In all likelihood, the majority of PGP users are probably still vulnerable, two weeks later.
But to be fair, the Enigmail and GPGTools developers have a much harder job than the Signal developers. On one side, they must work with an ancient crypto system; PGP dates to 1991, it was standardized as OpenPGP in 1995, and the popular PGP/MIME system was first standardized in 1996. On the other side they must deal with the ancient messaging systems out of which email is constructed and on which it travels, including the message sending protocol SMTP, first standardized in 1982, and MIME, a standard for attachments that emerged in 1992. They also need to ensure that their software works seamlessly with all other PGP software, in all its diversity. These standards all contain a multitude of obsolete, and often insecure, features in order to maintain backwards compatibility.
If Signal developers had to deal with decades of technical baggage and handle dozens of possible message formats instead of just one it would take them more than a few hours to fix similar vulnerabilities too.
Based on all of this, the “temporary, conservative stopgap” that EFF suggests — uninstall or disable PGP, and switch to secure messaging apps like Signal or Wire until the encrypted email ecosystem solves the EFAIL problems — sounds like pretty solid advice.
But unfortunately, for many of us, it’s not that simple.
Several communities of users have grown dependent on encrypted email to get their daily work done, including civil society communities like human rights and internet freedom activists, hacker and open source developer communities like the Debian project, and, increasingly, journalists and researchers who collaborate and work with sensitive sources.
Secure messaging apps are not a substitute for email, and they never will be. You can keep old archives of emails, and you can search these archives years later when you need to look something up. With email, you can participate in mailing lists, have threaded conversations, forward messages around, and leave things marked as unread until you have time to deal with them. After you publish a blog post, article, or academic paper, people can email you feedback, but you might not have time to reply right away, and you definitely don’t want this feedback making your phone buzz at 3 a.m.
Secure messaging apps are not a substitute for email, and they never will be.
For many of us, maintaining our same email habits but sending them without encryption is simply not a viable option. Asking us to temporarily stop using PGP for a while is the same as asking us to stop using email — it’s just not practical without completely changing how we’ve been working for years.
And while the fact that email and PGP are based on open standards makes it more difficult to maintain and fix security vulnerabilities, it also adds an enormous benefit: Email servers inter-operate with each other. You can send an encrypted email to my theintercept.com address from your gmail.com address, and I’ll be able to read it, but you’ll never be able to send a message to my Wire account from your Signal account. Because email is an open, federated system that has been around for as long as the internet, everyone has an email address; only some people use Signal, and others use Wire, WhatsApp, or Telegram, and some are only reachable on Facebook. None of these systems work with each other.
In my imagination, there exists a brand new email-like system: It uses modern cryptography like Signal does; it only supports a single, sane messaging format instead of endless permutations; and it has all the other qualities that email has, like the ability to maintain and organize an archive of old messages, and different servers that can communicate with each other. It doesn’t have decades of cruft to maintain and, importantly, it’s impossible to use it insecurely. But, since this email-like system only exists in my imagination, and not in reality, we’re stuck with PGP for the moment.
If you’re one of these PGP-dependent people like me, then make sure you pay close attention to the EFAIL developments, always keep your software up-to-date, and, if at all possible, disable viewing HTML emails. If you’re not one of these people, then by all means, just use Signal or similar messaging apps when you need to communicate securely.
But it’s also possible that I’m just biased. I would have an entirely different life right now if it weren’t for PGP.
On January 11, 2013, I received a PGP-encrypted email from an anonymous stranger. “I’m a friend,” the email read, once I decrypted it. “I need to get information securely to Laura Poitras and her alone, but I can’t find an email/gpg key for her. Can you help?” I didn’t know at the time, but this stranger was Edward Snowden, and he was in the early stages of blowing the whistle on the National Security Agency.
Correction: May 25, 2018
An earlier version of this story incorrectly stated that copies of encrypted emails could be obtained via National Security Letters or subpoenas. A search warrant is required for message content.