New vulnerabilities in many PGP and S/MIME enabled email clients. Allows exfiltration of plaintext by mauling HTML emails. A few thoughts. efail.de
In a nutshell, if I intercept an encrypted email sent to you, I can modify that email into a new encrypted email that contains custom HTML. In many GUI email clients, this HTML can exfiltrate the plaintext to a remote server. Ouch. 2/
It’s an extremely cool attack and kind of a masterpiece in exploiting bad crypto, combined with a whole lot of sloppiness on the part of mail client developers. 3/
The real news here is probably about S/MIME, which is actually used in corporate e-mail settings. Attacking and modifying encrypted email stored on servers could actually happen, so this is a big deal. 4/
Plus the attack on S/MIME is straightforward because it’s (a) a dumb protocol, and (b) a simple protocol not filled with legacy cruft, and (c) it’s built into email clients. Dumb and simple and one vendor to blame. 5/
But of course the attack also implicated the garbage-fire that is the PGP ecosystem so of course that’s what everyone is talking about. Over on HN the “its not PGP it’s mail clients” dance has begun so I guess we have to talk about that. 6/
So let me just cut through some of that. If you were using GnuPG on the command line and checking your error results, it’s absolutely true that you’re fine. If you’ve been using (one of several) GUI clients with PGP encryption, you were anything but fine. 7/
Put this differently: if any properly integrated messaging system like Signal or iMessage had similar flaws, we would all correctly say that the system was broken and unsafe. (In fact, we did: blog.cryptographyengineering.com/2016/03/21/att…)
But when it comes to PGP, the quality expectations on the crypto are low because it was invented in the Precambrian era. So it doesn’t do proper authentication except as an optional afterthought. 9/
Here’s Werner Koch’s explanation. See: PGP has supported proper optional message authentication (which stops this attack) since 2001, but it can’t be made mandatory because “some implementations haven’t kept up.” 10/ 
I JUST CHECKED AND IT IS 2018, WERNER. I THINK WE CAN MAKE AUTHENTICATED ENCRYPTION MANDATORY NOW. 11/
So in summary, PGP clients are vulnerable because 17 years after a vulnerability was known, the mitigation was not made a default in GnuPG and defense was instead “left to PGP clients”, which also make a convenient scapegoat when it goes pear-shaped. 12/
Moving on from the question of who is to blame, there are two neat findings in this work. The first is that most mail clients are (were) *way* too willing to reach out to remote servers, even when set up not to. This is: yikes.
The other stuff is more technical and of academic interest: PGP uses DEFLATE compression, which makes tweaking emails much harder — when you’re working blind and can’t see the plaintext. But even cruft like this is no real defense. 14/
So in summary: what do these attacks teach us? It’s frustrating because in terms of new flaws and mitigations, the answer is: almost nothing. 15/
In practical terms, however, the lesson is this: there is no such thing as a ‘theoretical vulnerability’. There are exploitable vulnerabilities, and vulnerabilities that haven’t been exploited yet. We need to build systems like we recognize this. 16/16
