Isn't this problem only with email that is not 100% encrypted, but contains an encrypted part inside an unencrypted part. So that type of mixed emails should always be treated with extra caution. A warning. And making sure that the encrypted bits get insulated from the unencrypted bit that may contain the bad bits of html. And something else?
Am I right to think that a 100% pure encrypted email cannot be the victim of EFAIL. But a main problem is that you cannot easily see what is in these invisibl
In https://www.golem.de/news/pgp-smime-thunderbird-update-notwendig-um... (in German), Hanno Böck discribes a problem of Enigmail that might also apply to GPGTools when remote content is disabled. He uses an HTML form with an invisible button covering the entire e-mail. A click anywhere in the mail window submits the form and leaks the decrypted plaintext.
I did not find any comments on that on the official twitter account. Do you have an eye on that? Or is there reason to believe that this attack would not work in Apple Mail?
It looks like the problem is with html in email first, and the treatment of multipart mails second. When combined with anything that is encrypted. The problem wasn't really with including images, although the <img tag was the first to use the efail trick.
Emails with just one single encrypted message, and nothing else should be safe. As they con't have any parts to put html in, that can run across the encrypted message.
Email readers that force some strong compartmentalisation of the parts could be safe. But that doesn't seem to be the way this mime thing has been set up.
I guess it makes sense within the current weak environment to have rather strong rules to only send encrypted messages without html, and only in one single part. As it is not easy to even see if there is html or not. And then the email reader is the only thing that can actually estimate if the email is of the (usual) type that is safe.
If I understand correctly, it is currently not safe to open an untrusted email with Apple Mail + GPGTools, even if loading remote content is disabled, right?
Shouldn’t that be reflected in the pinned tweet? Frankly, it would make EFF’s recommendation of temporarily uninstalling sound much more reasonable.
At some finite date in the (hopefully) near future, most email client over GnuPG users will have an EFAIL-reading safe system setup, if they don't already. MDC will be strictly enforced.
However, the situation for a secret message sending is not so good. There is no way to guarantee that the reader/receiver has updated their software and/or settings. Statistically speaking security updates are not enforced uniformly; there are always laggards. Therefore, without adequate additional precautions, there will always exist the possibility of a secret message writer/sender's message being read by an EFAIL attacker.
A solution to this problem is proposed in
"A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers"
Because each block is vulnerable, the solution works by individually protecting each block against being wholly included as part of an HTML attribute. It is possible because the attacker is restricted to dividing the message along encrypted block boundaries.
The solution is very simple. The plaintext to be encrypted in a single block is divided into two parts. This first part is obfuscating string o, and the second part is message m. The choice of o prevents m from being included in the attackers attribute value.
Specifically, the obfuscating string o must have a least the three characters single quote ('), double quote ("), and space ( ). That's enough for force the closure of the HTML attribute and protect the message m.
You can play around with the attackers choice of starting delimiters in this Try jsoup sandbox example
When decrypted by the user in its raw form the total message will be human readable but a little ugly because it contains the obfuscation string o, but it will be safe from EFAIL.
More detail is included in the above github document.
Because alignment of the obfuscation part with the encryption block boundary is critical, the implementation should be done in the base module, e.g. GnuPG, rather than an email client. Of course it is not a GnuPG fault, it just happens that's the obvious safe place for this proposed solution.