This is the right place to check for product updates and company news
May 17, 2018

Should we stop encrypting emails because of EFAIL?

The short is answer is: NO!

But make sure your mail client is configured not to load external email contents.

And the long answer?

The long answer is longer and you can read it below.

Why continue email encryption?

There might indeed be a chance that the contents of encrypted emails is exfiltrated. But what good could it do to stop encrypting all emails because of this?

The contents of some encrypted emails may be exposed. So don't encrypt any more?

This is obviously like putting out a fire with gasoline!

Should email encryption be considered broken?

Not really. Let's take a closer look at the problem listed in the EFAIL paper. It describes several ways to exfiltrate an encrypted email. However, they all have something in common:

How EFAIL works

The attacker inserts HTML code into message, for example by surrounding the encrypted block by an IMG tag in a way that the encrypted block is sent as a parameter to the server the SRC attributes points to.

Subject: Please answer asap
Content-Type: multipart/mixed;boundary="BNDRY"

Content-Type: text/html

<img src="
Content-Type: application/pkcs7-mime; smime-type=enveloped-data
Content-Transfer-Encoding: base64

Content-Type: text-html

In the mail client, the encrypted part is decrypted, then the email content is displayed. The unencrypted part is seen as part of the IMG SRC url, and an http request is initiated with this url, thus exposing the email content to the server. (If the email contents contains quotation marks, the text is exfiltrated only up to the first quotation mark.)

What the attacker needs

However, to make this attack work, several prerequisites must be met:

  • the attacker must have gained access to the email, for example by breaking in to the mail server
  • the mail client must accept multipart emails with a mixture of encrypted and unencrypted parts (which is unusual, but will probably work)
  • the mail client must evaluate the HTML and be configured to load external contents
  • the mail client must load external contents only after decryption

It all cumulates in the web server request caused by the IMG tag which exposes the decrypted message to the server in the IMG url. However, it is long known, that it is very dangerous to allow a mail client to load external contents. This applies to any email, and doesn't have anything to do with email encryption! 

What about the other scenarios?

The EFAIL paper describes more so-called backchannels, as well as techniques to attack the S/MIME or PGP encryption structure directly. Still, the aim is also to inject code that causes the email client to issue external requests in order to pass the decrypted text as a parameter. 

So if external requests are disallowed, the exfiltration attempt cannot succeed.


Configure your mail client to not automatically load external content. Never. Ever.

You mail client should already be configured like that, because it is long known that the automatic loading of external content is a very dangerous configuration. 

And it is important not to let your mail client load external content, no matter if it's an encrypted or unencrypted email!

Thanks for listening. (smile)

© 2007-2024 by savignano software solutions