E-Mail Vulnerabilities and Disclosure

Last week, researchers disclosed vulnerabilities in a large number of encrypted e-mail clients: specifically, those that use OpenPGP and S/MIME, including Thunderbird and AppleMail. These are serious vulnerabilities: An attacker who can alter mail sent to a vulnerable client can trick that client into sending a copy of the plaintext to a web server controlled by that attacker. The story of these vulnerabilities and the tale of how they were disclosed illustrate some important lessons about security vulnerabilities in general and e-mail security in particular.

But first, if you use PGP or S/MIME to encrypt e-mail, you need to check the list on this page and see if you are vulnerable. If you are, check with the vendor to see if they’ve fixed the vulnerability. (Note that some early patches turned out not to fix the vulnerability.) If not, stop using the encrypted e-mail program entirely until it’s fixed. Or, if you know how to do it, turn off your e-mail client’s ability to process HTML e-mail or—even better—stop decrypting e-mails from within the client. There’s even more complex advice for more sophisticated users, but if you’re one of those, you don’t need me to explain this to you.

Consider your encrypted e-mail insecure until this is fixed.

All software contains security vulnerabilities, and one of the primary ways we all improve our security is by researchers discovering those vulnerabilities and vendors patching them. It’s a weird system: Corporate researchers are motivated by publicity, academic researchers by publication credentials, and just about everyone by individual fame and the small bug-bounties paid by some vendors.

Software vendors, on the other hand, are motivated to fix vulnerabilities by the threat of public disclosure. Without the threat of eventual publication, vendors are likely to ignore researchers and delay patching. This happened a lot in the 1990s, and even today, vendors often use legal tactics to try to block publication. It makes sense; they look bad when their products are pronounced insecure.

Over the past few years, researchers have started to choreograph vulnerability announcements to make a big press splash. Clever names—the e-mail vulnerability is called “Efail“—websites, and cute logos are now common. Key reporters are given advance information about the vulnerabilities. Sometimes advance teasers are released. Vendors are now part of this process, trying to announce their patches at the same time the vulnerabilities are announced.

This simultaneous announcement is best for security. While it’s always possible that some organization—either government or criminal—has independently discovered and is using the vulnerability before the researchers go public, use of the vulnerability is essentially guaranteed after the announcement. The time period between announcement and patching is the most dangerous, and everyone except would-be attackers wants to minimize it.

Things get much more complicated when multiple vendors are involved. In this case, Efail isn’t a vulnerability in a particular product; it’s a vulnerability in a standard that is used in dozens of different products. As such, the researchers had to ensure both that everyone knew about the vulnerability in time to fix it and that no one leaked the vulnerability to the public during that time. As you can imagine, that’s close to impossible.

Efail was discovered sometime last year, and the researchers alerted dozens of different companies between last October and March. Some companies took the news more seriously than others. Most patched. Amazingly, news about the vulnerability didn’t leak until the day before the scheduled announcement date. Two days before the scheduled release, the researchers unveiled a teaser—honestly, a really bad idea—which resulted in details leaking.

After the leak, the Electronic Frontier Foundation posted a notice about the vulnerability without details. The organization has been criticized for its announcement, but I am hard-pressed to find fault with its advice. (Note: I am a board member at EFF.) Then, the researchers published—and lots of press followed.

All of this speaks to the difficulty of coordinating vulnerability disclosure when it involves a large number of companies or—even more problematic—communities without clear ownership. And that’s what we have with OpenPGP. It’s even worse when the bug involves the interaction between different parts of a system. In this case, there’s nothing wrong with PGP or S/MIME in and of themselves. Rather, the vulnerability occurs because of the way many e-mail programs handle encrypted e-mail. GnuPG, an implementation of OpenPGP, decided that the bug wasn’t its fault and did nothing about it. This is arguably true, but irrelevant. They should fix it.

Expect more of these kinds of problems in the future. The Internet is shifting from a set of systems we deliberately use—our phones and computers—to a fully immersive Internet-of-things world that we live in 24/7. And like this e-mail vulnerability, vulnerabilities will emerge through the interactions of different systems. Sometimes it will be obvious who should fix the problem. Sometimes it won’t be. Sometimes it’ll be two secure systems that, when they interact in a particular way, cause an insecurity. In April, I wrote about a vulnerability that arose because Google and Netflix make different assumptions about e-mail addresses. I don’t even know who to blame for that one.

It gets even worse. Our system of disclosure and patching assumes that vendors have the expertise and ability to patch their systems, but that simply isn’t true for many of the embedded and low-cost Internet of things software packages. They’re designed at a much lower cost, often by offshore teams that come together, create the software, and then disband; as a result, there simply isn’t anyone left around to receive vulnerability alerts from researchers and write patches. Even worse, many of these devices aren’t patchable at all. Right now, if you own a digital video recorder that’s vulnerable to being recruited for a botnet—remember Mirai from 2016?—the only way to patch it is to throw it away and buy a new one.

Patching is starting to fail, which means that we’re losing the best mechanism we have for improving software security at exactly the same time that software is gaining autonomy and physical agency. Many researchers and organizations, including myself, have proposed government regulations enforcing minimal security standards for Internet-of-things devices, including standards around vulnerability disclosure and patching. This would be expensive, but it’s hard to see any other viable alternative.

Getting back to e-mail, the truth is that it’s incredibly difficult to secure well. Not because the cryptography is hard, but because we expect e-mail to do so many things. We use it for correspondence, for conversations, for scheduling, and for record-keeping. I regularly search my 20-year e-mail archive. The PGP and S/MIME security protocols are outdated, needlessly complicated and have been difficult to properly use the whole time. If we could start again, we would design something better and more user friendly­but the huge number of legacy applications that use the existing standards mean that we can’t. I tell people that if they want to communicate securely with someone, to use one of the secure messaging systems: Signal, Off-the-Record, or—if having one of those two on your system is itself suspicious—WhatsApp. Of course they’re not perfect, as last week’s announcement of a vulnerability (patched within hours) in Signal illustrates. And they’re not as flexible as e-mail, but that makes them easier to secure.

This essay previously appeared on Lawfare.com.

Posted on June 4, 2018 at 6:33 AM33 Comments


Impossibly Stupid June 4, 2018 8:25 AM

Patching is starting to fail, which means that we’re losing the best mechanism we have for improving software security

I would argue that isolation is the best mechanism for keeping software (and hardware both) secure. My firewall keeps out the worst abusers before vulnerabilities are discovered or announced, let alone patched.

Sure, it’s hard to use communications tools like email while being isolated from the Internet, but that just means you shift the burden to elsewhere in the software stack. The “Unix way” used to be about individual tools, each written to do their job well, working together to get a job done.

These days we have mostly monolithic apps that try to do absolutely everything they can themselves. We really shouldn’t be surprised, then, when it turns out that not every developer is an expert on everything, resulting in a whole ecosystem of fragile products. Security is just one victim of that approach to software design.

Looking_For_DIME June 4, 2018 8:45 AM

Any update on the status of DIME (Dark Internet Mail Environment) as a replacement for email? Is the project abandoned?
I haven’t seen updates on darkmail info.

Slag June 4, 2018 8:47 AM

“Right now, if you own a digital video recorder that’s vulnerable to being recruited for a botnet — remember Mirai from 2016? — the only way to patch it is to throw it away and buy a new one”

And a million product designers sat up in interest. Planned obsolescence we can blame on someone else? That’s fantastic!

Oleg June 4, 2018 9:12 AM

IoT security will probably stay in “more hole than a fence” shape for looong time. There is no reason to believe that currect design practices would be modified, enormous time-to-market pressure common to FOTMs would be relieved, etc. It is almost web-centric software industry of 2010s, all over again.

I hear you on e-mail vs modern messengers comparison, but the very idea of using WhatsApp evokes image of jumping from frying pan into the fire.

Tisha June 4, 2018 9:14 AM

Looking_For_DIME, is there any good reason we need an entirely new protocol suite for secure email? Why not use existing key distribution mechanisms, with DNSSEC, and add a way to look up a .onion (Tor) SMTP address for an arbitrary domain (to hide metadata)? To control spam we’d want to identify the sender, which DKIM can do.

Bruce, re: “GnuPG… should fix it”, what do you suggest they do? Their software is designed to decrypt arbitrary data, with no understanding of that data and no knowledge of the program calling it. I don’t know of any email-related code in GPG. What can be done without increasing the attack surface?

parabarbarian June 4, 2018 9:25 AM

I might be missing something but this seems to me as less a problem with OpenPGP and more with HTML email. If my preference is plain text then there is no reason for my client to attempt a download. Same if I turn off the display of remote context when I do view the HTML message.

I use Thunderbird which makes it pretty easy to switch back and forth and I suppose some clients do make it difficult to turn off the HTML. Still that seems a problem with the email client not OpenPGP.

Andy Sherman June 4, 2018 9:51 AM

It seems to me that if any standard is the primary culprit in this attack it is MIME. Imagine how much easier this would be if the MIME spec said clearly that quoted strings were not allowed to span multiple parts.

Matthew June 4, 2018 10:02 AM

Neither Signal nor WhatsApp work in China. I don’t see people talking about this enough. Not just that one fifth of humanity is usually thrown under a bus in these discussions. But more importantly: in the long term, any secure comms system is doomed unless it works in China.

Network effects are king. If there’s a group of five people and one of them just can’t use WhatsApp, the whole group will use what that one person can use. That one person uses WeChat. Sure you can lose North Korea. Sure you can lose Iran. But the whole of China? No, that’s fatal. WeChat is rock-solid, feature-packed, has excellent marketing, and all your friends use it. What have you got?

You can cling on in the ghetto of only being used by those who truly need it. But that’s a downward spiral: fewer and fewer users who are more and more committed to learning the quirks, making it less and less appealing to anyone else. Using it marks you for attention, making it unusable by the very people who need it. And with so few maintainers, bugs don’t get fixed. GPG lies at the end of that road, and all the others will join it there in their turn.

I can’t see any plausible candidates to take on WeChat unless something truly amazing happens to OTR (the only federated, and therefore censorship-resistant, option you suggest). It takes a long time for this game to play out, but I hereby predict that you – I mean you, Bruce Schneier – will be using WeChat for the majority of your “private” conversations ten years from now. And I say that because much less than ten years ago, I was vowing I’d never touch the thing.

Gunter Königsmann June 4, 2018 10:31 AM

Normally it’s best if security issues are closed on all edges at the same time. But in the current case: by which means would the gnupg guys have a chance to fix this issue? That means: perhaps a better block cypher would have done the trick…

TheInformedOne June 4, 2018 10:33 AM

Convenience and Good Security will always be diametrically opposed. The mirage of “One Click” security has now exposed this principle. The flaw is not with the encryption, but with the implementation to make it easier to use. That encrypt button on the ribbon. That add-in or service which is always watching/running. I’m a bit surprised these vulns didn’t come to light sooner. There is a good reason why PGP protected email (inline) prior to “PGP/Mime” was plain-text only. Can email protection be both convenient and safe? Can developers create something both easy and safe? Answer: after 40 yrs. of trying….Absolutely NOT!!

PeaceHead June 4, 2018 10:38 AM

I am also concerned about the patch situation.
It is definately worrisome…

I fear that the golden age of computers is ending and we are entering a dark and dangerous age.
But who is pushing for the IoT? It’s not like there was a pre-existing demand for it. It’s not needed at all! So who is trying to shove it down our throats? Who are the corporations, individuals, and politicians or technocrats? I apologize if this was already answered; I may have missed the response.

mark June 4, 2018 11:30 AM

I’m so old, and have been online so long, that I remember when it was a joke on newbies to tell them that they could catch a virus by reading an email.

Until Bill the Gates made it possible.

I have my mail reader set to PLAIN TEXT ONLY*, and only open it, and view it as HTML if I am absolutely sure of who it came from… and if I’m not, that’s what “view source” is for.

Email, it’s like, writing a letter, so someone can read what you want to say to them in, like, words, man….

  • And I’m annoyed that thurnderbird seems to think that “oh, this is an invitation, I’ll display it as though I were in HTML view mode….”

Denton Scratch June 4, 2018 12:11 PM

“Of course they’re not perfect”

Indeed: everyone has a mail client. Not everyone chooses the same messaging client as you chose. Using proprietary ‘messaging’ tools drops you into a walled garden. The same thing happens with e.g. ProtonMail: to gain the full privacy benefits, you must refrain from corresponding with email users that don’t use ProtonMail.

@Bruce: disappointed that you again failed to point out that the problem here is not email, but the careless rendering of HTML email.

Incidentally: one advantage of the geekiness of email encryption is that people who are clueless are unlikely to try to use it. I for one have never received a PGP-encrypted message that had a text/html MIME-part.

echo June 4, 2018 12:21 PM

I don’t believe this problem is too complex or too much of a legacy issue. As an example the games or high performance graphics industry is well used to graphics functionality being split across different subsystem at both a logic level and also an API level. There is no reason a whitelisting type mechanism cannot be used to provide both security constrains or refactor in a forward moving way. As long as code is properly componentised and layered it is a realistic task to achieve. Both HTML and C/C++ suffer from bloated momentum and go from bad to worse simply because nobody can grasp the nettle.

Dealing with the issues at a hardware product level is a nightmare I will agree and certainly not helped by closed and locked down systems especially where design flaws introduced early with thin margin products make product recall near impossible.

I believe if the kernel of Bruces ideas are carried forward they could be built on in a way which helps both security but also more fixable approaches and may help with respect to forced obsolecence.

It would be ncie if we could return to the days when a brand and standards actually meant something instead of becoming vehicles for anonymous hedge funds and lawyers to maximise their incomes.

Wilheln Tell June 4, 2018 1:15 PM

including myself, have proposed government

Is your salary in any way dependent on government subsidies?

Patriot June 4, 2018 1:59 PM

Werner Koch worries me. His bizarre Shalom-Salaam sign off is not helping.

He knows that MDC packet is a weakness, but he protects it. Does this raise any doubts in anyone else’s mind besides mine? He was a perfect target–very poorly paid, the protector of the big problem, PGP.

The OpenPGP standard needs real authentication.

As far as this issue goes, our blog host is, of course, exactly right. The only email that I like and almost trust is Protonmail. It is end-to-end, their PGP keys are set up properly, they are in Switzerland, and their staff is first-rate.

When this incident happened, they went to work, analyzed the problem, and immediately shared what they learned, which was much.

You can make encryption work. Just start and end with secure end points.

Ted Hale June 4, 2018 2:04 PM

@mark “Until Bill the Gates made it possible”.

You might want to check your history. I was around to clean up after the Morris Worm of 1988. It spread via email and had nothing to do with Microsoft.

Taz June 4, 2018 3:43 PM


Spotted a reddit entry last week. Some guy was planning on building an onion server into all his IoT devices.

What a clever idea? Imagine if each of his onion servers used those access cookies?

echo June 4, 2018 5:00 PM

Speaking of secure endpoints would it be possible to build a secure path within a general purpose computer to provide encrypted keyboard/display/storage of a document with perhaps the critical component being a standardised plug-in allowing sourcing from any preferred supplier? Could something be cobbled together like dongles which can fit along the keyboard and display path and perhaps the storage path? This would need USB/HDMI/SATA components. I’m just not sure if this would work nor how it might provide interaction with the rest of the computer to maintain usability without interruption.

Thoth June 4, 2018 6:51 PM

If you are reallt going to trust your Intel/AMD/ARM Cortex A series backdoored processors from doing the encryption for you, good luck. Because you should be quite assured that those CPUs already have backdoor capabilites.

I would say if you really really really have something to hide, paper and pencil one time pad is the way to go but the only problem is key generation and key management which for myself, @Clive Robinson et. al., we have no problems with KM and have our own styles but that is not true for ordinary folks who are less willing to learn and take the hard way to get things dine right.

Oh, did I forget to mention that the keys stored for communication on your smartphones and desktop for your chat apps are mostly done insecurely ?

Hmmm … end of the day it is just hyped up security with misleading marketing because you can hack the computer, access a backdoor and many other techniques and the security of your communications becomes fully insecure.

Patriot June 4, 2018 7:37 PM

@ Taz

An onion server for the IoT is a fantastic idea. Let’s get busy. Such a system would be a win-win for consumers and industry.

On the other side of the infospace, you can bet some folks are working on public key kleptograpy for the IoT as we speak, reduced public keys for the exfiltration of small pieces of data.

Bob June 4, 2018 8:02 PM

I think matthew green misses the point. It’s reflected in bruce’s last paragraph too.

“If PGP went away, I estimate it would take the security community less than a year to entirely replace (the key bits of) the standard with something much better and modern.”

I doubt it. It could be argued that the existence of PGP could block the adoption of something better and modern, but not the development. The community understands that the bad parts of PGP are too big to ignore, so it develops better and modern tools. But they fail to replace PGP, because they are not adopted like PGP was? No, because they are not adopted like email was! PGP is not here to provide a secure tool for communication, it is here to provide a secure tool for email. And as long as email exist, PGP will and should exist too.

Maxwell's Daemon June 4, 2018 8:44 PM

@ Thoth

Well before Meltdown and Spectre, I’d already pulled my servers and pet (Tesla) supercomputer off the Internet. It’s the “Battle of the Five Armies++” out there, not just the “Wild, Wild West.” They have wired connections but that’s as far as that goes.

I do have three Internet facing devices, a laptop (i3) and two not very bright (what’s a trust-zone? 32-bit ARM) tablets. The former is where I do most of my (UNCLAS) research and entertainment. One of the tablets, with a broken touch-screen is what I monitor things and watch the Twitter-stream go by. The fully functioning tablet is for what they call “consumption” now. That’s a few thousand books and the World-Wide Web.

Occasionally I do have to handle something encrypted, aside from my crypto-containers that is, and it’s going to be “ASCII-armored” and done on the semi-secure servers. Handling sensitive communications any other way, as I know full well from my days in the military with a nuclear security clearance, aren’t supposed to be in the clear on an UNCLAS machine. [I’m also TEMPEST certified for repairs.] I might stretch to having a data-diode between the halves but I still don’t like it as the chips themselves, of any sort, are automatically suspect INMNSHO. Read “Ghost Fleet” by P. W. Singer*. I’d much rather copy the text to a multi-session, non-bootable, CD-ROM, destroying the each session after decryption, the same in the other direction.

By the way, this isn’t to protect me. That’s a dead issue since one signature by the right individual puts me back in uniform, despite my physical disabilities. “They” kept a tether on me. The NDA was five sheets, densely typed, and I really, really should have kept a copy. As an example. It’s the individual on the other side of the conversation, and the people I live with, that I keep in mind. “They” know exactly where I am and that’s not paranoia, just reality around my training, experiences, and medical care from the VA.

I still do maintain safe-practices here. As the phrase says, practice. To someone with serious OCD issues, procedures are reassuring.

Clive Robinson June 4, 2018 10:28 PM

@ echo,

Speaking of secure endpoints would it be possible to build a secure path within a general purpose computer to provide encrypted keyboard/display/storage of a document

The answer to the above is a partialy qualified yes.

It all depends on how you define and use certain words, and how they relate to the physical reality of both the conmunications paths and the security paths within the communications paths.

Each communications path at it’s simplest is a “Shannon Channel”. These are simplified simplex paths through a communications medium from a transmitting point (TX) and receiving point (RX) with charecteristics defined by the laws of nature as we currently understand them.

It is important to not that one Shannon Channel can be the medium for another Shannon Channel. They are in effect nested, with inner channels inheriting properties from the next channel outwards. Thus any limitation any given channel imposses is also inhereted by the subsequent inner channels.

You could think of the channels a little like “Russian Dolls” where the size or volume of an inner doll is constrained by the next doll outwards. You can extend this idea with security in that each doll can be seen as the surface of a security zone in a similar way as people do with layers of an onion or kernel of a nut.

More practically think of it as a nest of tubes or layers arranged coaxially one inside the other. Thus an given inner layer inherits the security of the layers outside of it and the layers inside of it inherit any properties or limitations it imposes.

You can see from this that as long as the communicating parties stay inside the inner zone then any information is at it’s most secure. Further to remain secure the endpoint of any given layer needs to be beyoned the layers outside of it.

As the basic communications layer is outside of the more secure inner layers,

    The communications end point must be before the security end point.

This is a fundemental rule that if broken renders the system open to the use of side channels by an attacker to bridge information out from inner layers to outer layers across intervening layers effectively rendering them null and void.

Thus you can use an ordinary PC etc as a communications device without risk as long as the security end point is beyond the end point of the layer the PC is used at.

So consider the basic innermost information layer it’s Shannon Channel transmiter (TX) is the first communicating parties fingers and the receiver is the second parties eyes (in security parlance they are Alice and Bob respectively).

On the assumption[1] this innermost layer is plain text this would be an attackers (Eve or Mallory) ultimate target. Thus the keyboard Alice types on and the screen Bob reads on need to be beyond the security end point which in turn is beyond the communications end point. Thus the practical reality is a computer used in a communications link should not be used for the security end point, nor should the keyboard or screen be connected to it.

Think of it if it helps like an old school serial terminal connected to another distant terminal running a chat program or equivalent,

1, Alice’s keypress gets converted by her terminal into plain texy serial data.
2, This is sent to an inline encryptor that is the security end point.
3. The inline encryptor converts the plaintext serial data to ciphertext serial data.
4, This is sent to the communications endpoint which connects to a communications network.
5, At Bob’s end the process is reversed and the letter Alice pressed is displayed on his terminal screen.

It is easy to see that the various endpoints are segregated by what are mandated interfaces that ensure the various layers are issolated from each other.

With the design of modern computer equipment it is not possible to segregate the seperate parts. Thus side channels can exist and leak plaintext from the secure channel layer into the insecure communications channel layer.

To do what you want to do you need seperate devices where information can not leak from input to ouput. Such hardware is difficult to design and even has it’s own “code word” of “TEMPEST”.

In the past I’ve listed up the basic design rules and indicated why they exist and which law of nature they use or mittigate.

But the rules PC’s etc break most frequently are those to do with both segregation and leaking information due to “Efficiency-v-Security”.

[1] Actually it need not be plaintext, it could be “end to end” ciphertext that is traversing a communications node, where “link encryption” is used on the individual communications paths. It would still make the innermost layer an attackers target but probably with regards to “Traffic Analysis” rather than cryptanalysis currently.

name June 4, 2018 11:51 PM

Simplest and best way to report an overt vulnerability in critical informational infrastructure?

echo June 5, 2018 8:30 AM


So it is possible? I don’t completely follow the working out but know what you mean. Ish. Anything to avoid tedious paperwork…

TRX June 5, 2018 9:56 AM

the huge number of legacy applications that use the existing standards mean that we can’t.

Er. Everything that didn’t support PGP or S/MIME was a “legacy application” at one time, too.

We’re basically down to Outlook and Thunderbird, which I suspect have virtually all of the mailreader market. Webmail… even with https, you’re trusting that the host’s web server isn’t scarfing your private message even as you type it in…

TRX June 5, 2018 10:08 AM

There is no reason a whitelisting type mechanism cannot be
used to provide both security constrains or refactor in a
forward moving way.

The last time “whitelisting” came around, it seemed only corporate e-mail servers insisted on it. And most of those whitelist systems were either too much of a hassle to put up with, or didn’t work at all. (which, considering corporate attitude toward email in general, might have been a feature)

So, being unable to contact their sales department at their posted email address (and getting the “voicemail box is full”), I crossed them off and moved to the next vendor on the list. Sure, most of them were only piddly orders for a few hundred or a few thousand dollars, but all it would have taken was a simple 15-second reply to have gotten the one for $25,000…

Billikin June 6, 2018 1:41 PM

As a paranoid layman my defense against the internet of things is not to buy anything that uses the internet without my control. I hope I don’t have to throw away my digital recorder.

Years ago I had a firewall that let me control outgoing messages. Now I can’t even control what Firefox sends out.

justina.colmena June 7, 2018 4:58 PM


Mueller reportedly asked witnesses to hand over their phones so he could inspect their conversations on encrypted messaging apps.

No wonder encryption is so broken. Every phone call is a political party line, and every email message is a political list.

No wonder the Dems have so much trouble with LGBT these days. Some brother man dude fellow guy reportedly owes money to the local p1mp for that phone call answered by the local girl, so he has to pay up or “come out” as a fa66ot, because like well a gentleman isn’t really allowed to mind his own business anymore, and straight men pay straight up to keep their good reputation.

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.