A Digital Security Trainer’s Lessons from #Efail
Harlo Holmes
May 18, 2018
At around 2 AM on the morning of Monday, May 14, I was just starting to close my eyes and drift off to sleep when my phone buzzed a few times. I thought about ignoring it, but I picked it up from off of the nightstand. Signal was alight with news from my friends warning of a “set of vulnerabilities” in PGP and S/MIME that pose an “immediate risk” to anyone who relied on those protocols to protect their confidential communications.
Sleep was canceled. I jumped out of bed, made a few calls to ask follow-up questions, combed through Twitter to corroborate details and read up on experts’ speculation. By daybreak, more light had been shed onto the disclosure, and we learned that the vulnerability did not stem from PGP, the protocol, or from GPG, the software implementation. Instead, the vulnerability was with how certain popular email clients handle error states when presented with maliciously-crafted, HTML-based content in PGP- and S/MIME-encrypted email.
That said, OpenPGP’s API could have thrown a fatal error, rather than just a warning, when a message validation (MDC) failure occurs in their API. This decision left the burden of error handling to third party developers, and its lack of clarity might have contributed to dangerous error state handling. Anyways, there have been several excellent post-mortems on the vulnerability and its response. I encourage everyone to read them; we do not need to rehash them here. Instead, let’s unpack #efail for its more evergreen advice.
Threats to press freedom around the world are at an all-time high. Sign up to stay up to date and take action to protect journalists and whistleblowers everywhere.
Thanks for signing up for our newsletter. You are not yet subscribed! Please check your email for a message asking you to confirm your subscription.
I've long thought HTML email is the work of the devil, and now we have proof I was right. But did you people listen? You never listen.
We know that there are huge opportunities for an adversary to slurp up data via HTML requests in email. #Efail demonstrated this principle to the extreme. When conditions are just right, an HTML asset can be crafted to append your decrypted data as a parameter to the attacker’s request, and Bob’s your uncle. Luckily, getting that secret data is difficult, and that’s why we still consider PGP safe (flaws and all).
But the real lesson here can be found in methods of data exfiltration. Whenever an asset like an image, font, or widget is requested, the viewer calls out to the address on remote servers where that’s hosted. Most email clients are designed to make email look pretty when you load them; they allow such connections directly from your inbox by default. So while the vast majority of us will never encounter the ideal #efail adversary, we encounter little “chupadados” every day; hell-bent on using the same techniques to find out when, where, and how we’ve interacted with their servers each time we open our inboxes.
This is a huge privacy fail, and email clients should uniformly provide us protection against that, should we ask for it. #Efail amplified that message loud and clear. Until all email clients catch up, take control of your privacy by disabling remote content on your computers and phones by following our guide.  Or, if you’re incredibly concerned about any HTML elements displaying in your email client, look into a command line client like Mutt. (I did, and I never looked back!)
This saga represents a very specific nightmare in encrypted communications: one day, due to an insurmountable vulnerability (as in #efail’s case), an advance in brute-forcing power, a discovery of a persistent backdoor, whatever, it will become trivial for an adversary to go back in time and read everything you ever thought you kept private. For many, PGP feels like a Sword of Damocles, because it’s an ecosystem that lacks perfect forward secrecy.
Perfect forward secrecy attempts to solve this “time machine” problem. Instead of having one key that decrypts everything forever, what if you had a trusted set of rotating keys that could only decrypt what you needed right now? This is a really cool innovation as far as privacy goes: if an adversary grabs one of your keys, they’d only have access to a small, ephemeral subset of information. They would not have any access to your complete history or further information to come.
So, this is why tools that offer end-to-end encryption as well as some form of perfect forward secrecy are especially important. Signal, Wire, and WhatsApp already implement it. Semaphor and Keybase are among a growing number of services that have PFS on their roadmaps. There are also apps that support a protocol called Jabber (XMPP) that’s federated, meaning that your friends don’t even have to have the same app as you have to chat privately. Unlike the other options, you can chat with anyone on desktop or mobile using a client that similarly supports Jabber and the privacy plugins OTR and/or OMEMO! (Check out ChatSecure, Conversations, Coy.im, and Zom for more.)
Everyone should still be cautious: end-to-end encryption is moot if there are plaintext copies of conversation accessible to third parties. For example, WhatsApp might log your plaintext conversations to your iCloud by default, and so taking control of such “insecurity defaults” is as important as anything else.
I always say, like the game Othello, PGP takes a minute to learn and lifetime to master. Since most people first encounter PGP through integration with email, they mostly (mistakenly) believe that it ends there. Combined with the fact that it’s so darn cumbersome, and unwieldy on mobile in most cases, PGP in email is not the most efficient way to have timely conversations in a secure space. It is for this reason that it makes much more sense to migrate to services that are ubiquitously accessible, and still offer the most privacy possible.
That said, even though newer tools are more suited to more stringent confidentiality needs, PGP and GPG are still excellent tools to learn and use. Like a lot of you, I continue to use PGP in two major ways:
Open Source is awesome, and PGP plays an integral role in verifying Open Source Software. For heavy Linux users, adding developers’ public keys is the first step to getting cool new stuff installed and keeping it properly updated. No matter your operating system, everyone should verify the integrity of packages before clicking “Install.”
..But they don’t offer end-to-end encryption, and I’m protective of my stuff! Those tax returns from a few years ago? Those old grad school term papers? Those MP3s of your high school band? Encrypt them before you upload them to a cloud service like Dropbox or Google Drive, and you won’t have to worry about third parties gaining access without your say-so.
It takes two to tango, and it takes (at least) two to have a meaningful conversation. Security is as much a cultural challenge as it is a technological one. This means, it’s absolutely imperative that everyone in your “secret chat group” value your collective privacy equally, and take steps to realise this goal. The most important, first step, is to ask yourself if you’re keeping your software up-to-date for the sake of herd immunity.
Software has bugs. Circumvention software are high targets for nation-state adversaries and smart alecs alike. Tool developers (ideally) don’t want to see their projects fail, and (ideally) take care to issue patches when they learn about vulnerabilities. Want a great example of how even the best of the best are not without flaws? Check out CVE-2018-1000136 and CVE-2018-11101. So, whether you’re using PGP, Signal, Telegram, or a mixnet of carrier pigeons, when updates are available, update!
Let’s not be glib: nestled exploits in circumvention technologies can be incredibly dangerous, even deadly. Their primary users are those with the most at stake, and they’re usually the ones against whom these exploits are first weaponized. Ultimately, it’s on each of us in the digital security training space to analyze vulnerability disclosure events not only for greater understanding of how specific technologies break down, but also how these breakdowns reverberate across technology in general.