There's a lot of talk about EFAIL:

The EFAIL attacks exploit vulnerabilities in the OpenPGP and S/MIME standards to reveal the plaintext of encrypted emails. In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs.

So, what should I as an end user do in response to this? Should I immediately stop sending and/or recieving encrypted email? Or perhaps all emails? Or stop using PGP for anything at all? Is there some quick fix? Patches to install? And if so, patches to what? Other actions to take?

Note that this is a question about what to do as an end user. It's not about the inner workings of the vulnerability or how to fix the problem on the protocol level.

  • 4
    Yes, I know this question is largely answered in the provided link. But I thought it would be good to address this issue on this site as well, as I suspect there will be a lot of interest in this. – Anders May 14 '18 at 14:00
  • 3
    I wonder whether disabling HTML rendering in email client would help. If you only display message as plaintext, no images will be fetched from remote server, and thus the exploit should not work. – Martin Vegter May 14 '18 at 14:12
  • 4
  • 1
    @MartinVegter, likewise wondering (and therefore posting as comment not an answer), but I should think unchecking the "Load Remote Content in Messages" option should be enough. (That still allows HTML rendering, but any remotely hosted images will be left blank and not fetched.) – Wildcard May 14 '18 at 21:57
  • 1
    The real vulnerability is in those app handling both clear and cypher text at the same time ... – Xavier59 May 15 '18 at 6:11

Notably, PGP is not the problem. The problem lies with the mail handling apps in your browser which you have allowed to use your PGP keys. Those browser apps decrypt the message as they should, but inside that message in addition to your secret is a trojan URL which is an attackers site. Your browser app stupidly tried to connect to the URL which has your secret appended at the end.

For most people the most practical method is (from your link):

Short term: Disable HTML rendering. The EFAIL attacks abuse active content, mostly in the form of HTML images, styles, etc. Disabling the presentation of incoming HTML emails in your email client will close the most prominent way of attacking EFAIL. Note that there are other possible backchannels in email clients which are not related to HTML but these are more difficult to exploit.

Then any URL in the decrypted message will appear as text, including the trojan URL. Almost certainly would you be able to look at the URL and know something was wrong. If nothing was wrong, and if your mail program has a button to to allow you toggle HTML view for that single mail, you would then be able to safely read the mail.

The other method suggested:

Short term: No decryption in email client. The best way to prevent EFAIL attacks is to only decrypt S/MIME or PGP emails in a separate application outside of your email client. Start by removing your S/MIME and PGP private keys from your email client, then decrypt incoming encrypted emails by copy & pasting the ciphertext into a separate application that does the decryption for you. That way, the email clients cannot open exfiltration channels. This is currently the safest option with the downside that the process gets more involved.

could be more difficult. On a cell phone it could be very very difficult. On a laptop or desktop, it depends on how easy it would to set up the non-browser app, or have someone do it for you. The fiddly time spent cutting and pasting depends on how many encrypted messages you have to process.

You would also want to be careful that the non-browser app doesn't automatically try to contact the URL.

EDIT: Adding quotes to message won't protect your sent encrypted mail. Thanks to @Anders for pointing out the reference.

  • 2
    "mail handling apps in your browser" – isn't this backwards? I understand the vulnerability to be in the 'browser' (HTML parser) in email apps/clients. – Kenny Evitt May 14 '18 at 20:36
  • 1
    One example: Firefox is a browser, and Thunderbird is a client app installed by the user in Firefox. Still no PGP capability. Then the Enigmail add-on is installed onto Thunderbird. Enigmail contains the code that does the decryption, but Thunderbird scans that decrypted result (like an ordinary mail) finds the URLs and automatically tries to display them. So I would say it is the scanning code (HTML parser sounds right) which is called by Thunderbird that is doing the actual leaking. If so, then it Thunderbird that needs to be modified to sandbox the decrypted data. – Craig Hicks May 14 '18 at 21:26
  • 16
    @CraigHicks What the heck? Thunderbird is not a client app running in Firefox (they at least at some point shared the xulrunner framework). That does not make any sense. It also does not scan the result automatically for URLs or something. It displays the embedded HTML in an embedded browser-like thing. – Jonas Schäfer May 15 '18 at 6:25
  • 4
    Mistakes of crypto engineering in OpenPGP and S/MIME—and generally incoherent security goals—are absolutely part of the problem here. Modern public-key encryption schemes do not admit the selective modification that efail uses to trigger the exfiltration channels; a forger can only replace messages wholesale. – Squeamish Ossifrage May 15 '18 at 12:41
  • 2
    @JonasWielicki - You're right. Thunderbird is a >desktop< email client not a browser email client. Thunderbird should sandbox the decrypted result and scan for URL's or otherwise toxify before "It displays the embedded HTML in an embedded browser-like thing.". – Craig Hicks May 15 '18 at 16:54
  1. Disable HTML rendering. (Not HTML sending: HTML rendering. It doesn't matter what mail you send; what matters is what your mailer does on receipt of the adversary's mail.)

  2. Consider configuring your mailer to disable automatic PGP key download, S/MIME OCSP verification, S/MIME CRL download, S/MIME intermediate CA download; consider periodically updating your keyrings and certificate stores instead. There's a tradeoff here: You may shoot yourself in the foot by failing to notice revoked certificates and you may deanonymize yourself with batches of related downloads, but your mailer's automatic key download or OCSP verifier or CRL downloader may shoot you in the foot.

  3. Consider disabling automatic decryption in your mailer. There's a tradeoff here: You may shoot yourself in the foot by raising the barrier to communication so high that you don't want to do it any more, but your mailer's automatic decryption may shoot you in the foot.

  4. Follow thegrugq's guide to how to use PGP if you must use PGP for defense against a serious threat model and you're willing to use the command-line gpg tool with all the mental overhead that implies. (Read the OpenSSL man pages if you must use S/MIME, but don't expect the OpenSSL command-line utility to stand to scrutiny…)

  5. If you know anyone connected to OpenPGP or S/MIME development, support their efforts to make them use modern cryptography engineering and articulate meaningful security goals in real-world applications like mailers and package verification, not just the gpg command-line tool. (Don't clamor on Hacker News because humanity has already exceeded its HN hot air quota.)

  6. Use Signal.

  7. Read more details at crypto.se.

  • 4
    Can you explain what #2 has to do with efail? – Bergi May 15 '18 at 8:08
  • 1
    @Bergi There are several different exfiltration channels. If the attacker edit a partially known message to put an unknown part—say they turn out to be the bytes 0a 1b 2c 3d—in the position of an OpenPGP key id in the signature, they may be able to cause your mailer to download http://pool.sks-keyservers.net/pks/lookup?search=0x0a1b2c3d&op=get. This applies similarly to S/MIME OCSP, CRL, and CA URLs. – Squeamish Ossifrage May 15 '18 at 12:43
  • "You may shoot yourself in the foot by raising the barrier to communication so high that you don't want to do it any more" - I'd call that a win if it means not opening Outlook any more. – Max Vernon May 15 '18 at 19:05

There is another solution apart from disabling HTML rendering - which you nonetheless should.

This is a list of affected clients and webmailers1:

List of affected clients, webapps and webmailers

The efail attack in its current form relies first and foremost on a client vulnerability. If you are using one of the affected clients, you might want to think about changing to another one for the time being, although that may not be a solution in the long term. Also keep your client and your S/MIME and/or PGP plugin updated. Supposedly Enigmail 2.0 already mitigates Efail.1

{1} https://efail.de/efail-attack-paper.pdf
{2} https://www.heise.de/newsticker/meldung/Efail-Was-Sie-jetzt-beachten-muessen-um-sicher-E-Mails-zu-verschicken-4048988.html

  • Are all clients/webmailers in that list affected, or should I look at the colors, and if so in which column(s)? – user178109 May 15 '18 at 9:50
  • Below the list are is an explanation of the four symbols that were used. Green means that the client is not affected. Red means that the client is affected without user interaction. – Tom K. May 15 '18 at 10:19
  • So as an example, "Evolution" has one red and three green. Affected or not? Is the S/MIME column relevant, or should only look at PGP? (I honestly don't know...) – user178109 May 15 '18 at 10:24
  • 1. In general: S/MIME and PGP are two different standards for public key encryption (PKE). You can use either one or both (or none). Some clients do not provide interfaces for either one, so an end user has to install plugins. 2. Your specific example: Evolution seems to support both S/MIME and PGP. Furthermore the implementation for S/MIME seems to be affected by the efail attack, while its PGP implementation is not. If you use PGP for encryption and use Evolution as a client, you are - as far as we know now - not vulnerable to the efail attack. If you use S/MIME and Evolution, you are. – Tom K. May 15 '18 at 10:31

The current advice is to avoid automatically decrypting the email in your email client. In most cases that means uninstalling the relevant plugin. You then need to copy the encrypted text to a separate application to view it.

You should still be able to send encrypted mail, provided that the receiver is taking the appropriate precautions, although that would probably mean using the problematic plugins.

As per Martin Vetger's comment, disabling automatic html rendering can also largely mitigate the attack, although the researchers also said that there were other channels available that could be exploited with more work.

What that means to you as an end user will vary quite a lot.

In order to benefit from this exploit the attacker has to be able to modify the email message in transit, or resend an email that they have previously captured. Obviously multiple nation states or your employer can do this, but I suspect you are unlikely to find many criminals running a dodgy wi-fi hotspot hoping to grab some sensitive personal information from your PGP emails.

If you are just privacy minded then you could probably just carry on. The email will still be encrypted on the mail server, and GCHQ/NSA etc may be able to grab it, but law enforcement can't use it against you.

You could look to restrict the firewall rules on your machine too, so that the mail client can only communicate on 1 or 2 ports. That would block the html vector completely and potentially cut off a lot of other avenues for exfiltration.

If lives are at stake then abandoning it is best...

  • +1 for mentioning the option to block the mail client via firewall rules. – not2savvy May 15 '18 at 14:37

Short term fixes

There are two short term fixes to choose between:

  1. Disable HTML rendering in your email client. (And note that's rendering HTML, i.e. viewing it, not sending it.)
  2. Stop decrypting email in your email client (e.g. by disabling the PGP plugin), and instead copy paste the encrypted data into a separate program to do the decryption.

The EFAIL webpage makes references to potential ways of exfiltrating data without HTML, so just doing #1 might not be completely safe. That is probably why EFF recommends #2 as well. So while #2 is less conveniant, it is probably more secure.

Install updates

Since the vulnerability lies in how email clients interact with PGP, you will want to update your email client and any plugins to it. When the problem is fixed in your email client, you could stop with the short term measures. Both #1 and #2 are reasonable security precautions even in absence of EFAIL, though, so if you gotten into the habit of using them you might as well continue.

OpenPGP or any of it's implementations aren't inherently broken, so while you should always keep your software up to date there is no need to update them specifically because of this. Nor will you have to stop using them.

Remember the other participants

Since both the sender and all recievers can decrypt emails, the EFAIL attack can be directed at any of these. So even if you take the above precautions the messages you send and recieve may still be decrypted if the people you communicate with are less prudent.

For the time being, you may want to take this into consideration before using these tools.

Your Answer

