DEV Community

Cover image for EFAIL mitigations
Daniel Waller (he/him)
Daniel Waller (he/him)

Posted on

EFAIL mitigations

As you might have heard there is a flaw in many popular email clients that allows an attacker to decrypt PGP or S/MIME encrypted email content.

Here's the website with all of the info about the attacks: EFAIL

Let's collect mitigation techniques especially for the clients affected by the direct exfiltration attack (Apple Mail, iOS Mail, and Mozilla Thunderbird)

Some immediate mitigations I've read about so far:

  • Turn off OpenPGP and S/MIME encryption in your mail client and use an external tool (eg. Keybase) for encryption/decryption by copy-pasting content.
  • Disable HTML support. Only show plaintext
  • (For Thunderbird) Leave OpenPGP encryption enabled but turn off automatic decryption/verification of messages in Enigmail settings

A screenshot of thunderbird with the 'Enigmail' dropdown menu open and the selection on the menu item 'Automatically Decrypt/Verify Messages'

  • (For Thunderbird) Disallow remote content in messages.

A screenshot of thunderbirds preferences with the 'Privacy' tab selected and the mouse cursor hovering over the checkbox 'Allow remote content in messages'


The last 2 just protect you from stumbling into the attack. You can still be exploited if you accept remote content for that particular mail and/or if you manually decrypt the message.

Top comments (5)

elmuerte profile image
Michiel Hendriks

Not much to do with PGP. The flaw is with loading external content in HTML emails. This has always been a way to spy on readers. This is just one of the reasons I prefer text/plain for email.

Mutt doesn't have any of these issues. It handles multipart mime as intended. Not sure if it is affected by the fact that GPG only issues a warning instead of failing in case of a missing MDC. But despite that, it doesn't allow any spying.

danielw profile image
Daniel Waller (he/him)

Yeah I really don't like all the hyped up coverage about "OMG PGP encryption is broken!!1!" because it's misleading and people are probably still on the safer side using encryption.
Plus the attack vector is preeetty specific and would likely only concern some high profile individuals

rrampage profile image
Raunak Ramakrishnan

On Twitter, some of the infosec people were mentioning that updating your Thunnderbird to 52.7 or Enigmail to the latest version solves the issue for you only i.e any other client/device which runs the old software is still vulnerable to the issue.

danielw profile image
Daniel Waller (he/him)

Yeah I think that is something that has to be stressed here. All parties in the communication have to be safe.

craigphicks profile image
Craig P Hicks

I have posted a document:

A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers

It's a very simple proposal. The plaintext of every encrypted block is prefaced by an obfuscation string part which prevents the message string part vcoming after it from being part of the EFAIL attribute. The EFAIL can attack each block seperately, but it can't divide and conquer a block itself.

The obfuscation string needs to contain a double quote ("), a single quote ('), and a space ( ). You can immediately see how it works by looking at this HTML sandbox:
where you can play around with the choices the EFAIL attacker has and the opportunities to defend against it.

It depicts a typical 16 bytes string to be encoded in a single block, but it is safely prefaced by an obfuscation string.

Did I mention it has to be uncompressed? Because compression ruins the boundary alignment. And of course for any reader who doesn't have software to remove the obfuscation parts, the mail is ugly, although still readable.

More technical details are in the document.

I have tried to offer a whole system cost/benefit analysis at the end.

If it were to be implemented it would have to be implemented close to the encryption/decryption, e.g. inside the GnuPG module. That is because aligning the obfuscation string with the encryption block boundary requires close coordination. Too easy to make a mistake otherwise.