GPGMail and efail: Everythings safe?

joern poenitz's Avatar

joern poenitz

14 May, 2018 10:51 AM

  1. Support Staff 1 Posted by Steve on 14 May, 2018 11:35 AM

    Steve's Avatar

    Hi Joern,

    GPG Suite 2018.2 which mitigates against this attack is coming very soon.

    As a temporary workaround against efail

    1. open Mail > Preferences > Viewing
    2. Disable option to "Load remote content in messages"

    Kind regards,
    steve

    efail_setting.jpg

  2. 2 Posted by Lorena on 16 May, 2018 08:22 AM

    Lorena's Avatar

    According to the Q&A of the attack, that might not be enough to be safe :)

    https://efail.de/#i-have

  3. 3 Posted by Nichol on 16 May, 2018 11:01 AM

    Nichol's Avatar

    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

    What are the plans for the coming upgrade?

  4. 4 Posted by Paul on 22 May, 2018 02:26 PM

    Paul's Avatar

    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?

  5. 5 Posted by Nichol on 22 May, 2018 07:06 PM

    Nichol's Avatar

    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.

  6. 6 Posted by Paul on 22 May, 2018 07:20 PM

    Paul's Avatar

    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.

  7. 7 Posted by Craig Hicks on 23 May, 2018 03:16 AM

    Craig Hicks's Avatar

    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"

    https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki

    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

    https://try.jsoup.org/%7E_nyXks5PuAs-zJeek8CVhpuAvtI

    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.

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac