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
- (For Thunderbird) Disallow remote content in messages.
Note
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)
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/plainfor 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.
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
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.
Yeah I think that is something that has to be stressed here. All parties in the communication have to be safe.
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:
try.jsoup.org/%7E_nyXks5PuAs-zJeek...
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.