The Efail Scam: What You Should Do as a User of Apple’s

June 4th, 2018 by
Apple Mail Icon

You have probably heard of the recent hype about OpenPGP/GnuPG/etc. and S/MIME having been compromised. Actually, that’s not true. What has been discovered, is that the ways that many email apps make use of OpenPGP and S/MIME are vulnerable to exploits. Make no mistake: the OpenPGP and S/MIME encryption schemes and tools themselves are still safe to use. It’s the mail clients that are to blame.  Here is what you can do to minimise your attack surface as a user of Apple’s

How the Attack Works

The Efail exploit makes use of two convenience features many mail clients offer to make handling encrypted emails easier, and a (IMO) design flaw in all current email clients. The first convenience feature is to analyse the email message’s content, and to automatically decrypt any encrypted message parts. The second convenience feature is to cache the passphrase needed to unlock your secret key. On macOS, this is usually done by adding it to your keychain. The design flaw in current email clients is to store encrypted messages in their encrypted form. This requires messages you are sending encrypted to others, to also be encrypted to yourself (or else you would never again be able to read what you just sent).

Under the Efail attack, the hacker needs to have obtained an encrypted email message you have sent to someone in the past. With SSL being used as the default by most email servers nowadays, this will not be easy at all. But, for the sake of argument, let’s assume you’d been careless, and had not used SSL to send your encrypted email. The hacker is not able to make any sense of the old message, since it’s encrypted. What he needs to do now, is create a new email message, addressed to you, He will need to forge the message headers to make it appear to come from someone you know, or otherwise incentivise you to open the message. The message’s body will be in HTML format, which Apple’s, ands many other mail clients, will happily render in the message viewing window to give you nice fonts, bold, etc.

Inside the HTML message body, the clever hacker has included a copy of the your old encrypted email message, but wrapped in HTML formatting to make it invisible (e.g. small, white text on white background, in a 2×2 pixel rectangle). The mail client will detect encrypted content, but of course it has no concept of “invisible content”. It will therefore go about decrypting the encrypted part, replacing it with the decrypted cleartext. The cleartext sits there, but you cannot read it.So far, no harm done. The clever hacker has also included some JavaScript with his HTML, however. This JavaScript will access a remote server (which is controlled by the hacker), and will upload the entire HTML document (including the cleartext of your old message) to that server.

If your secret key’s passphrase is stored in your keychain, all this will happen silently, without you even noticing.

What You Can (and Should) Do

The first thing you should do, and that’s probably also a good idea to minimise being tracked, is to prevent Apple’s from silently accessing remote servers when displaying HTML messages. This is done via Mail > Preferences > Viewing.’s message viewing preferences

Make sure that the “load remote content in messages” option is not checked. Now, whenever an HTML email message contains references to stuff on remote servers, you will be presented with a blue bar across the top of the message window:

Remote content warning in the message viewer

Think twice before you click on “load remote content”! Usually, the remote files are stationery images and similar. In most cases, you will likely be able to figure out the message’s information content without those. If the message is totally unreadable without the remote content, consider asking the sender to re-send in a different format, which does not require you to download remote files.

If you’re using OpenPGP to encrypt email messages in Apple’s, then you are most likely using the fabulous GPG Suite which comes with a plugin for Apple’s Here is the second thing you should do, which is to prevent your secret key passphrase from being cached and silently used. Go to the Apple menu, open System Preferences, and locate the “GPG Suite” entry in the bottommost row:

Open it to reveal GPG Suite’s settings. Here, you need to make sure that the two options in the password category, i.e. “Store in macOS Keychain”, and “Remember for X seconds” are not checked. After that, click on the “Delete” button to the right of these two options. This will ask for a confirmation, which you should allow.

These two steps will result in, and any other en- or decryption operation involving your secret key, to prompt you for your passphrase. You may be surprised how often that is the case. This allows you to opt out of decrypting (by hitting the ESC key or clicking “cancel”), whenever something doesn’t seem right. Suppose you received a forged email message as described above, which is a 5-liner, inviting you to a meeting. Why does it ask me for the passphrase the third time over? Or if the visible part of the message was not encrypted, why does it ask for the passphrase at all?

Yes, all these measures reduce the comfort level, and more interaction on your part will be required. But then, security never comes for free. Plus, these are temporary measures, which would no longer be needed, once we rethink email, and redesign email clients from the ground up. One of our next posts will describe what we think should happen. So “stay tuned!” 😉