Twitter | Search | |
Hector Martin
Since the Efail guys and are failing at actually documenting mitigations, here they are: - Use Enigmail 2.0 or later - Use Thunderbird 52.7.0 or later That's it. That fixes both the GPG issue and the back channels. If you've been running up to date software, *you're fine*.
Reply Retweet Like More
Hector Martin 14 May 18
Replying to @marcan42
If you're paranoid or running older Thunderbird, set network.http.speculative-parallel-limit=0 and network.dns.disablePrefetch=true. The former is already set on the latest version, the latter isn't but I wasn't able to reproduce it, so I assume they fixed it a different way.
Reply Retweet Like
Hector Martin 14 May 18
Replying to @marcan42
Note that *either update* to Enigmail or Thunderbird is sufficient to mitigate; the exploit relies on *both* (for GPG anyway, but nobody uses S/MIME, right?). But you want the Thunderbird update/config fix for privacy reasons anyway (otherwise mail trackers could work).
Reply Retweet Like
Hector Martin 14 May 18
Replying to @marcan42
Oh and of course don't enable autoloading remote content and don't manually override it, since that of course defeats the whole purpose of the back-channel fixes. But if you're using encryption you're already privacy-conscious enough to not do something silly like that, right?
Reply Retweet Like
Hector Martin 14 May 18
Replying to @marcan42
Looks like the DNS prefetch issue was a screwup by the Efail authors. They listed it as a problem in the preprint provided to Enigmail, but the final paper doesn't have it, and as far as I can tell that's been fixed for 8 (!) years. So yeah. Just one leak in old TB (preconnect).
Reply Retweet Like
Hector Martin 15 May 18
Replying to @marcan42
Another important timeline tidbit: GPG has been failing with an error (not a warning) in cases of missing MDC since 2.1.9 (released in 2015). So as long as you have a version newer than that (and the client honors errors) you're fine too, e.g. for most commandline users.
Reply Retweet Like
Hector Martin 15 May 18
Replying to @marcan42
Note that *really old* encrypted messages, using ciphers prior to the introduction of MDC, are still vulnerable (if you have a side channel in the mail client). This is fundamental: those messages are using older crypto without integrity protection. GPG cannot error out on those.
Reply Retweet Like
Hector Martin 15 May 18
Replying to @marcan42
The only real solutions for those, besides mail clients plugging the side channels/app-level issues with those, are to either refuse to decrypt them outright (not great) or have an application-level warning and click through.
Reply Retweet Like
Hector Martin 15 May 18
Replying to @marcan42
So you cannot roll back the integrity protection on a message encrypted with modern gpg (because modern ciphers are tied to a hard MDC requirement), but old legacy messages are stuck back in that era, without the integrity protection.
Reply Retweet Like
Hector Martin 15 May 18
Replying to @marcan42
It seems the plan was already to fully deprecate those old cipher suites with GPG 2.3 (the next major version), thus basically erroring out on decrypting old messages without an override, to plug this particular hole (at the expense of really old emails).
Reply Retweet Like
Joona 14 May 18
Replying to @marcan42 @EFF
...and make sure that all of the recipients / people sending you email do that too.
Reply Retweet Like
Hector Martin 14 May 18
Replying to @joohoi @EFF
That's their problem, not yours. This is a universal issue with encrypted communications. If any party is compromised, the communications are compromised. This is no different from e.g. someone getting their computer pwned with malware.
Reply Retweet Like