0:00:00.000,0:00:18.070
35C3 preroll music
0:00:18.070,0:00:24.070
Herald: The following talk is about email[br]encryption. Who worries that their email
0:00:24.070,0:00:32.800
encryption might be capable of being[br]hacked or cracked? Worry not as far as I'm
0:00:32.800,0:00:40.050
told it still is rather secure. But. And[br]the but will be answered by Sebastian
0:00:40.050,0:00:45.879
Schinzel who is one of the eight security[br]researchers who uncovered the drama and
0:00:45.879,0:00:54.829
the details behind e-fail. A recently[br]occurred issue with OpenPGP and S/MIME
0:00:54.829,0:00:59.600
in a lot of email clients. All the[br]technical details he will dig into so
0:00:59.600,0:01:03.339
please give a warm hand of applause for[br]Sebastian Schinzel.
0:01:03.339,0:01:09.850
applause
0:01:09.850,0:01:15.080
Sebastian: So it's good to be back. Thank[br]you everyone for coming. My name is
0:01:15.080,0:01:22.080
Sebastian. It's my fourth talk here at the[br]CCC. And the other talks that I did were
0:01:22.080,0:01:27.260
also on encryption so I somehow like[br]encryption and I like analyzing encryption
0:01:27.260,0:01:31.320
and I like to break encryption. So I did a[br]talk on TLS where we found an attack
0:01:31.320,0:01:39.070
against TLS and against XML encryption for[br]example. And I usually start my talk by
0:01:39.070,0:01:45.030
asking Who's using this this specific[br]technology, right? Because when you when
0:01:45.030,0:01:49.710
you usually when you're analyzing or doing[br]a talk about a communication protocol you
0:01:49.710,0:01:57.144
ask the people who's using that and you[br]know for e-mail it would be silly, right?
0:01:57.144,0:02:00.200
Because, who's using e-mail. [br]Every one of you is using e-mail.
0:02:00.200,0:02:04.921
OK. Because I don't know. I mean when you[br]started using the Internet like
0:02:04.921,0:02:10.369
in the last 20 years or so usually[br]the first thing that you do you dial in
0:02:10.369,0:02:13.409
onto the Internet and you make[br]yourself an e-mail address, right?
0:02:13.409,0:02:20.980
So everyone has everyone uses e-mail. But[br]let's take a look at how things work when
0:02:20.980,0:02:25.359
when you send an email. So when you click[br]in your email client when you when you
0:02:25.359,0:02:30.329
compose an email and you click into your[br]email client "Send". So the first thing is
0:02:30.329,0:02:34.989
on one of your devices you're using the[br]local network and there's a green arrow
0:02:34.989,0:02:40.790
because it's under your control. So you[br]can define by yourself how secure this
0:02:40.790,0:02:45.560
link is gonna be. Then you use the next[br]connection and the next connection will be
0:02:45.560,0:02:50.437
to your SMTP server. And this is also a [br]green arrow because it's under your control.
0:02:50.437,0:02:53.344
Okay. You can control this [br]and usually it's TLS.
0:02:53.344,0:02:58.950
The same as valid for your IMAP[br]folder because always when you send an
0:02:58.950,0:03:07.180
email via SMTP you will upload a copy to[br]your "sent" folder on IMAP and it uses TLS
0:03:07.180,0:03:12.379
in most of the cases so therefore the[br]arrow is green. The arrow is not that
0:03:12.379,0:03:17.659
green anymore when it comes to the backup[br]strategy for example an archiving strategy
0:03:17.659,0:03:23.599
of your email provider which may be gmail[br]or gmx for example or your company. OK.
0:03:23.599,0:03:27.370
But you may have a chance to know the[br]administrators and ask him whether they
0:03:27.370,0:03:33.579
are doing a good job and stuff like[br]that. You're also - it's not under your
0:03:33.579,0:03:38.840
control where else your email is uploaded[br]to. So for example in order to check it
0:03:38.840,0:03:44.620
for antivirus or anti spam and stuff like[br]that, right? So it gets uploaded to some
0:03:44.620,0:03:50.389
cloud, right? Because you want to do a[br]spam filtering and then it goes out to the
0:03:50.389,0:03:54.200
Internet and you know we learned what's[br]happening on the Internet. People are
0:03:54.200,0:04:00.459
listening in on the Internet and we heard[br]from Edward Snowden for example that many
0:04:00.459,0:04:05.150
nation state actors and agencies are[br]doing this as well they are listening into
0:04:05.150,0:04:11.549
your e-mails or they at least try to. And[br]then the arrows get red as soon as it hits
0:04:11.549,0:04:16.431
the SMTP server of the receiver. Right.[br]Because you don't really know whether they
0:04:16.431,0:04:21.250
are using TLS, encryption in any case. You[br]don't know whether they upload it to
0:04:21.250,0:04:27.040
another antivirus vendor or so and then it[br]gets uploaded to the IMAP folder to the
0:04:27.040,0:04:31.990
inbox of the receiver where it gets[br]archived again, right? There is a backup
0:04:31.990,0:04:38.310
is being done and stuff like that, it's[br]archived. And then finally the receiver of
0:04:38.310,0:04:42.831
the e-mail has the ability to check his[br]own email and retrieve the e-mail
0:04:42.831,0:04:49.150
from his inbox. OK. So even if you know[br]that the other person that you've just
0:04:49.150,0:04:53.490
sent the e-mail to does a good job in[br]securing it and uses encryption everywhere
0:04:53.490,0:04:56.380
and so on and so on.[br]You never know whether there's some
0:04:56.380,0:05:01.780
attacker or so who has compromised the[br]infrastructure and so on and so on. OK.
0:05:01.780,0:05:06.790
And this problem multiplies.[br]When you send an e-mail to multiple people
0:05:06.790,0:05:11.140
because then all of a sudden the e-mail[br]that you just sent, your e-mail, hits
0:05:11.140,0:05:17.270
infrastructures of many other people. OK?[br]So many people have access to this
0:05:17.270,0:05:22.140
e-mail and this is the first thing that I[br]want to - this is the first point that I
0:05:22.140,0:05:27.430
want to make in this talk. People usually[br]talk about their e-mail. It's my e-mail,
0:05:27.430,0:05:31.960
you know? And when I run my own mail server[br]it's going to be secure but this is not
0:05:31.960,0:05:36.630
the case. I mean the the point of[br]using e-mail is distributing it to your
0:05:36.630,0:05:40.030
friends to your colleagues and so on and[br]so on because we want to exchange.
0:05:40.030,0:05:43.430
It's a communication method but the[br]communication is archived so people
0:05:43.430,0:05:52.120
archive this and so on and so on. So it's[br]it's a mess basically. OK. So for the rest
0:05:52.120,0:05:56.090
of this talk we need to have some[br]assumption that someone has access to the
0:05:56.090,0:06:02.091
e-mails. OK. Because right. We just[br]learned that it's distributed. You're
0:06:02.091,0:06:05.620
archiving your own e-mails in your IMAP[br]folder and so on and so on I have the
0:06:05.620,0:06:09.520
e-mails of the last 15 years or so in my[br]in my IMAP folder and if someone gets
0:06:09.520,0:06:14.940
access to it - right - boom. I have a[br]problem. Okay. And in order to cope with
0:06:14.940,0:06:19.090
this people came up with end-to-end[br]encryption. And there's two competing
0:06:19.090,0:06:28.180
standards out there. The first one is[br]OpenPGP. It was first defined in 1991 from
0:06:28.180,0:06:32.340
Phil Zimmermann invited it. And this was[br]like this happened in the first crypto
0:06:32.340,0:06:39.400
wars. So this is a very interesting story.[br]And it's the most widely used e-mail
0:06:39.400,0:06:42.940
clients they they support OpenPGP but[br]only when you when you download the
0:06:42.940,0:06:48.590
plug-in, OK? For S/MIME you usually[br]have native support in most of the
0:06:48.590,0:06:52.900
applications so you just get an S/MIME[br]certificate and off you go.
0:06:52.900,0:06:57.020
You can just use it and it just works out[br]of the box but it's mostly used by
0:06:57.020,0:07:01.530
corporate organizations and military for[br]example right. Not so much by privacy
0:07:01.530,0:07:06.700
advocates like OpenPGP.[br]Now we can't measure very well how many
0:07:06.700,0:07:11.230
people use S/MIME. We tried but there[br]doesn't seem to be a public source where
0:07:11.230,0:07:15.790
we can measure this but we can do it on[br]PGP because PGP has key servers and you
0:07:15.790,0:07:19.520
can upload your key there so that people[br]can communicate with you in a secure
0:07:19.520,0:07:26.150
manner. And this statistic here is the[br]amount of new published public keys per
0:07:26.150,0:07:32.920
month. And it started off very low in[br]1997. Then in 2003 we saw a constant rise
0:07:32.920,0:07:39.600
until 2013 where we see a a spike here[br]where it more than doubled. Does anyone
0:07:39.600,0:07:43.330
know why we saw this spike in 2013?[br]Someone in the audience: Snowden!
0:07:43.330,0:07:48.560
Sebastian: Snowden right. Edward Snowden[br]we had the Snowden revelations and Edward
0:07:48.560,0:07:54.060
Snowden uses PGP to communicate with the[br]journalists who did the actual, like,
0:07:54.060,0:07:59.639
disclosure of the documents. And so we see[br]this in the uploader keys so people use
0:07:59.639,0:08:05.500
PGP much more. We also see this in [br]the amount of daily users of Enigmail
0:08:05.500,0:08:10.560
which is the plugin for Thunderbird. [br]And you can extract this
0:08:10.560,0:08:16.400
information and there we also see around[br]2013 we see a jump and it increased by 50
0:08:16.400,0:08:21.140
percent or so something like this. So[br]people use PGP, right? It's not that many
0:08:21.140,0:08:25.210
when you compare it to how many people use[br]e-mail a few hundred thousand is not that
0:08:25.210,0:08:31.580
much but still it's a substantial number.[br]The problem here is we know for a fact
0:08:31.580,0:08:38.000
that in the last 20 years or so especially[br]non-technical users are not able to use
0:08:38.000,0:08:43.860
PGP in a secure manner. Okay. So we have[br]the first paper from '99: "Why Johnny
0:08:43.860,0:08:49.091
Can't encrypt" and then we have a follow[br]up paper from 2006: "Why Johnny still
0:08:49.091,0:08:54.700
can't encrypt", OK? So OK. Must've[br]been better I hope and then in 2015 we
0:08:54.700,0:09:00.460
have "why Johnny Still, Still can't[br]encrypt". OK? so we have a long story
0:09:00.460,0:09:06.170
where people try to use PGP but failed,[br]OK? And this is not something that is
0:09:06.170,0:09:13.310
inherent in an OpenPGP. We have the same[br]papers for S/MIME where they said
0:09:13.310,0:09:18.240
novice users - and where they confronted [br]novice users with with S/MIME and they
0:09:18.240,0:09:23.260
failed, basically. They weren't able to [br]use it in a secure manner. Okay.
0:09:23.260,0:09:29.240
So therefore in order to enable people to[br]use PGP, especially PGP and S/MIME in a
0:09:29.240,0:09:34.300
secure manner you have many tutorials out[br]there. And this is a very interesting
0:09:34.300,0:09:38.900
tutorial because it's the original video[br]that Edward Snowden recorded in order to
0:09:38.900,0:09:44.480
teach Glenn Greenwald how to use openPGP.[br]It's still on Vimeo. The original video is
0:09:44.480,0:09:49.330
still there. And what is interesting there[br]is he doesn't recommend a plugin for an
0:09:49.330,0:09:55.170
email client. He basically says just use[br]web mail and use this PGP standalone
0:09:55.170,0:10:00.460
application type your message there click[br]encrypt and copy and paste the ciphertext
0:10:00.460,0:10:06.040
into your web mail, OK? So there's no[br]integration and others recommend for
0:10:06.040,0:10:13.120
example Enigmail or GPGtools. Enigmail is[br]the plugin for Thunderbird and GPGtools is
0:10:13.120,0:10:18.390
the plug in for Apple mail, which [br]means that most of them had HTML
0:10:18.390,0:10:22.970
switched on which is an interesting fact.[br]OK. For something that we are going to
0:10:22.970,0:10:29.340
talk about later. So I thought about how[br]can I do this talk. And this is how I came
0:10:29.340,0:10:33.650
up with the agenda. So we start off with[br]some attacks that are very I find pretty
0:10:33.650,0:10:37.260
interesting. At least for an academic they[br]are pretty interesting, and we slowly
0:10:37.260,0:10:42.300
degrade to pretty silly attacks and you[br]decide for yourself whether you would fall
0:10:42.300,0:10:47.720
for it or not. I came to the conclusion[br]that I would probably fall for them. OK,
0:10:47.720,0:10:53.780
I lied. So we start off with something[br]that is even worse than silly. So what is
0:10:53.780,0:10:58.210
it what's the worst thing that can happen[br]when you're sending an encrypted mail.
0:10:58.210,0:11:00.570
Audience: You send your private key.
0:11:00.570,0:11:03.690
Sebastian: if you send your private key[br]there would be bad. What's even worse?
0:11:03.690,0:11:06.290
Audience: You forget to encrypt.
0:11:06.290,0:11:11.770
Sebastian: you send a plain text. Okay[br]okay. So in 2014 there was a bug in
0:11:11.770,0:11:16.210
Enigmail which is documented in their bug[br]tracker. So basically you compose an e-mail
0:11:16.210,0:11:19.860
you tell Enigmail to sign and encrypt[br]it, and then you send it and it will be
0:11:19.860,0:11:27.860
sent in plain text. Okay. Oh okay. This is[br]not good. In 2017 Outlook did it much better
0:11:27.860,0:11:32.710
because they did encrypt it but they[br]packed the plain text along with the
0:11:32.710,0:11:42.350
ciphertext. (Audience: laughing) Okay. Bad.[br]And then in 2018 you may remember this is
0:11:42.350,0:11:48.270
just a few months back or so Enigmail or[br]pretty easy privacy. It's a plugin to
0:11:48.270,0:11:52.660
Enigmail, so a plugin to a plugin that's[br]actually used for novice users. It gave
0:11:52.660,0:11:57.040
the feedback that the email that you're[br]composing will be encrypted but it wasn't.
0:11:57.040,0:12:04.529
Okay. And the good news here is: the[br]e-mail attacks don't apply here because,
0:12:04.529,0:12:10.230
OK, I mean, it's about I don't want to make[br]fun of any developers. The point that I'm
0:12:10.230,0:12:16.010
trying to make here is that email is a[br]plaintext protocol and it's always very
0:12:16.010,0:12:21.890
difficult to make a protocol that was made[br]for plain text delivery - to make this
0:12:21.890,0:12:26.040
encrypted. When you have a plaintext[br]fallback you're into trouble. Okay. And we
0:12:26.040,0:12:33.710
we saw the same basically with HTTP and[br]HTTPS. OK. So HTTPS is like now secure but
0:12:33.710,0:12:37.640
they hit the same issues right and[br]browsers and so they were falling back to
0:12:37.640,0:12:42.529
HTTP and so on and so on. So it's really[br]really difficult. Now that we have this
0:12:42.529,0:12:47.920
out of the way. Okay. We tried to look at[br]the interesting interesting box and before
0:12:47.920,0:12:53.580
we start I want to make a short[br]introduction into how the cryptography in
0:12:53.580,0:12:59.610
S/MIME and PGP work. And I just make one[br]introduction because both are the same
0:12:59.610,0:13:03.000
from the viewpoint of the attacks that I'm[br]going to present. Okay. Both are very
0:13:03.000,0:13:08.770
similar actually. So we start off by[br]writing a message, m, this is here we
0:13:08.770,0:13:13.760
generate a session key, s, that that's[br]basically a random session key and we use
0:13:13.760,0:13:19.780
this session key to encrypt the message[br]and make a cipher text, c, and we use AES
0:13:19.780,0:13:26.390
or triple DES for example any symmetric[br]cipher will do here.
0:13:26.390,0:13:31.910
Then we use this session key that we just[br]generated and encrypt this with a public
0:13:31.910,0:13:37.160
key of the recipient and we get a K and we[br]pack this K into the message so everything
0:13:37.160,0:13:43.040
will be packed into a message and sent off[br]to the receiver. The receiver then
0:13:43.040,0:13:49.050
obtains the encrypted email he starts[br]extracting the ciphertext K and the
0:13:49.050,0:13:56.490
ciphertext C. From K he decrypts s which is[br]the session key, right? And with s he can
0:13:56.490,0:14:02.580
decrypt the ciphertext C and retrieves m.[br]And so both have the same message. Okay.
0:14:02.580,0:14:06.670
So it's basically a hybrid encryption you[br]use symmetric encryption for the actual
0:14:06.670,0:14:11.740
encryption off the message and then[br]asymmetric encryption to just encrypt this
0:14:11.740,0:14:17.870
session key. Now, if you attended my[br]previous talks I talk a lot about
0:14:17.870,0:14:23.940
ciphertext malleability. So you make tiny[br]changes to a cipher text and it will lead
0:14:23.940,0:14:28.589
to predictable changes in the plaintext[br]which is strange, right? So we would
0:14:28.589,0:14:33.529
assume when we just flip a bit here[br]somewhere, okay? Here's a bit that just
0:14:33.529,0:14:37.470
flipped and where we decrypted we get[br]something like this. Usually you would
0:14:37.470,0:14:42.860
think OK. It's total garbage. Nothing[br]sensible should come out of
0:14:42.860,0:14:47.120
this but we see something like this. Most[br]of the message is still intact. We just
0:14:47.120,0:14:54.920
have a few randomly looking junk binary[br]stuff in there and we see one changed
0:14:54.920,0:14:59.850
character here. That used to be "email"[br]and now it's "efail". Okay so there was
0:14:59.850,0:15:04.240
just some bit flipping happening here. In[br]order to understand this we need to
0:15:04.240,0:15:08.990
introduce something that we called a mode[br]of operation. AES or any other block
0:15:08.990,0:15:14.910
cipher has the property that it uses[br]blocks. In most cases it's 16 bytes.
0:15:14.910,0:15:20.520
And when you want to encrypt more than 16[br]bytes you need to call AES multiple times
0:15:20.520,0:15:25.470
and you split it into blocks and CBC is[br]one way of connecting these ciphertext
0:15:25.470,0:15:30.580
blocks so the decryption works like this.[br]You have the first ciphertext block the
0:15:30.580,0:15:36.839
second ciphertext block and the third[br]ciphertext block. Only the second one is
0:15:36.839,0:15:43.019
decrypted so C1 is decrypted using AES and[br]your key for example. And the result here
0:15:43.019,0:15:50.000
is not directly the plaintext but it will[br]be XORed with C0 which will we would also
0:15:50.000,0:15:55.470
call an initialization vector. Okay so[br]whatever is written in here will be XORed
0:15:55.470,0:16:00.550
on whatever comes out of this description[br]and we get this plaintext here. Now when
0:16:00.550,0:16:06.970
we flip a bit or when we change a certain[br]byte in C0 we change whatever comes out
0:16:06.970,0:16:11.930
here of the decryption and we will[br]flip the same bit at the same position in
0:16:11.930,0:16:18.891
the plaintext which is interesting because[br]now when we say we use the original c0 and
0:16:18.891,0:16:27.410
XOR it with p0. So when we XOR it when we[br]XOR two times the same value we get
0:16:27.410,0:16:33.870
basically a block of all zeros which is[br]like a blank sheet of paper that we can
0:16:33.870,0:16:38.570
write on and we call this thing - these two[br]blocks here in combination - we call this a
0:16:38.570,0:16:45.060
CBC gadget because we can reuse it as as[br]much as we want. And when we now take a
0:16:45.060,0:16:51.190
chosen ciphertext the nice thing is here[br]we just XOR it - the chosen ciphertext on
0:16:51.190,0:16:55.730
this initialization vector and it means[br]that it will here result in a chosen
0:16:55.730,0:17:00.640
ciphertext.[br]So this requires that we know the value of
0:17:00.640,0:17:06.870
p0. We need to guess this value of p0. And[br]this is always true at least for S/MIME
0:17:06.870,0:17:11.770
because all S/MIME emails start with a[br]content type so we always know the first
0:17:11.770,0:17:18.549
bytes. So this is valid. We can do this[br]now. This was like the perfect
0:17:18.549,0:17:23.949
scenario. It does have some drawbacks[br]because when we tried to do the same for
0:17:23.949,0:17:30.080
C1 we switch, we flip, a bit here then we[br]flip a bit also here. But the decryption
0:17:30.080,0:17:35.360
of C1 results in this random junk and we[br]can't do anything about it. We don't know
0:17:35.360,0:17:39.890
whatever will come out here and we can't[br]control it. Okay we just have to deal with
0:17:39.890,0:17:44.300
it. It's gonna be there when we use the[br]CBC gadgets and we have to deal with it.
0:17:44.300,0:17:49.480
We have to find a way to deal with it and[br]now we can explain this behavior, you know?
0:17:49.480,0:17:53.799
You remember this e-mail where we just[br]flipped a single bit and we saw one block
0:17:53.799,0:17:58.950
was destroyed basically. And then the[br]other block we had like we can flip
0:17:58.950,0:18:04.410
arbitrary bits. That's the explanation[br]for it. Now how do you how do
0:18:04.410,0:18:09.090
you deal with it. How should a proper[br]crypto protocol deal with it. Usually you
0:18:09.090,0:18:13.170
do something that is called a message[br]authentication code. It's not a digital
0:18:13.170,0:18:19.010
signature and message authentication code[br]is something like a checksum a
0:18:19.010,0:18:24.240
cryptographic checksum that is [br]put right next to the
0:18:24.240,0:18:28.170
encrypted message and that can be[br]checked after decryption or for
0:18:28.170,0:18:31.160
decryption. OK? The message[br]authentication code is solely there to
0:18:31.160,0:18:36.480
detect changes of a ciphertext. Digital[br]signatures are different especially in the
0:18:36.480,0:18:40.840
mail context because they're pretty[br]much totally separate from
0:18:40.840,0:18:47.460
the decryption part. So digital signatures[br]are merely only used to display an icon
0:18:47.460,0:18:55.710
for example for valid signature or invalid[br]signature. And the problem here is a smart
0:18:55.710,0:19:01.090
attacker can use a signed email and strip[br]off the signature. Okay. We just strip off
0:19:01.090,0:19:06.260
this part that we know there's a signature[br]we can remove the signature and then this
0:19:06.260,0:19:09.980
doesn't mean there will be an invalid[br]signature but will get something like
0:19:09.980,0:19:15.770
this. This is the icon in thunderbird for[br]encrypted and not signed so we can simply
0:19:15.770,0:19:21.970
strip off a signature and there's valid[br]reasons to send an encrypted email without
0:19:21.970,0:19:27.720
doing a digital signature on it, right? So[br]we want to do both. So digital
0:19:27.720,0:19:34.080
signatures won't prevent this[br]attack. So how does S/MIME look like?
0:19:34.080,0:19:39.170
Basically, I mean, most of you will have[br]heard of MIME. MIME is like a standard
0:19:39.170,0:19:45.310
that we use in emails anyway. Here[br]we have an e-mail header. It looks very
0:19:45.310,0:19:50.600
similar to HTTP. We have content type,[br]colon, empty space, and then it's
0:19:50.600,0:19:56.640
whatever is coming now for data. And then[br]we have an e-mail body with envelope data
0:19:56.640,0:20:01.040
and there we have the list of the of the[br]encrypted session keys that this
0:20:01.040,0:20:08.040
ciphertext was encrypted with. And after[br]that we have the encrypted content info
0:20:08.040,0:20:12.580
here. This part is the encrypted part[br]where the actual message where the actual
0:20:12.580,0:20:17.490
message lies. And now when you look[br]closely and you squint you see there's no
0:20:17.490,0:20:22.540
message authentication code and it's not[br]because I left them out but because S/MIME
0:20:22.540,0:20:26.669
doesn't define one. So S/MIME doesn't have[br]a message authentication code which
0:20:26.669,0:20:33.040
means it cannot detect bye the standard[br]whether a message was changed - whether
0:20:33.040,0:20:36.780
it was changed or not.[br]So how can we attack this?
0:20:36.780,0:20:41.590
How can we use it? I think you all have a[br]feeling that this shouldn't work, OK? This
0:20:41.590,0:20:46.950
is nothing that is supposed to work.[br]This is the plain text that we want to
0:20:46.950,0:20:51.210
exfiltrate and we only know the first[br]block. We can pretty much always guess the
0:20:51.210,0:20:56.380
first block because it's always content[br]type: text/html or text/plain something
0:20:56.380,0:21:03.960
like this. Now we can use this as a gadget[br]here and write our arbitrary plain text.
0:21:03.960,0:21:08.331
We have a random block and then chosen[br]plain text. Then we copy it again. We
0:21:08.331,0:21:12.780
again have a random block and some chosen[br]plain text. Then we have a random block
0:21:12.780,0:21:17.051
and a chosen plain text. Then we have a[br]random block and a chosen plain text. Then
0:21:17.051,0:21:23.780
we copy here the original ciphertext and[br]we close this thing. And when you look
0:21:23.780,0:21:28.120
closely again you'll see that we're[br]building HTML here right. That's the base
0:21:28.120,0:21:33.920
tag. That's an image tag. It uses a URL.[br]That is not closed here. It will be closed
0:21:33.920,0:21:40.490
down here. And this is effectively the[br]URL. OK. A URL-path and will thus be
0:21:40.490,0:21:45.200
exfiltrated. So when this XML is[br]interpreted the actual plain text is sent
0:21:45.200,0:21:51.750
to the server. And here we have an old[br]Thunderbird. So that is a version of
0:21:51.750,0:21:58.100
before May and before we did the[br]disclosure. We first compose a message
0:21:58.100,0:22:03.419
just to have some PGP ciphertext. This is[br]a very secret message. And here we have
0:22:03.419,0:22:09.850
the attack e-mail that is already[br]prepared. And now it asks us
0:22:09.850,0:22:13.820
"This remote content in here. What do you[br]want to do?" And we just for the
0:22:13.820,0:22:19.370
laughs just - like this - we just click it[br]and we see always now when we select the
0:22:19.370,0:22:27.320
message an HTTP request is done to this[br]to this URL. And when we decode this - it
0:22:27.320,0:22:32.330
looks pretty - it's encoded. But basically[br]what we have here now you see here is the
0:22:32.330,0:22:37.370
secret message and here is random junk.[br]And here again is random junk, right? So
0:22:37.370,0:22:43.400
it was successfully exfiltrated. This was[br]the first proof of concept that we had.
0:22:43.400,0:22:50.540
Right? And. Okay right? And so this works.[br]This is like - this
0:22:50.540,0:22:54.900
dialog here that you get in Thunderbird[br]that ask if should I should a load remote
0:22:54.900,0:22:59.580
images. Yes or no. This is basically[br]everything that is keeping you from losing
0:22:59.580,0:23:06.400
your your PGP or S/MIME ciphertext - S/MIME[br]we're talking about S/MIME here. Now what we
0:23:06.400,0:23:11.650
did next was we were asking ourselves, OK:[br]It works with remote images. We understand
0:23:11.650,0:23:16.200
this ,but what other back channels do we[br]have? Back channel is something where
0:23:16.200,0:23:20.690
your email client is communicating[br]over the network. That's. So it's not
0:23:20.690,0:23:26.460
necessarily exfiltrating but it's just[br]like how can we convince a client to make
0:23:26.460,0:23:33.150
a connection to somewhere else. Now I[br]colored in red all the e-mail clients that
0:23:33.150,0:23:37.940
require user interaction - that always[br]require user interaction before it
0:23:37.940,0:23:44.600
opens up a network connection somewhere.[br]In orange we say that there's no user
0:23:44.600,0:23:49.840
interaction. So these are the clients that[br]allow for example loading remote images by
0:23:49.840,0:23:54.470
default. OK. There's mail app for example[br]there's gmail for example. They will not
0:23:54.470,0:24:00.470
ask you they will just load it, OK? And[br]but what we think is worse and therefore
0:24:00.470,0:24:06.000
we colored it red are the clients that say[br]we won't load remote images or any other
0:24:06.000,0:24:11.650
way of communicating over the network. But[br]then they will because we want bypasses.
0:24:11.650,0:24:16.711
So because preventing loading remote[br]images is basically a firewall and we
0:24:16.711,0:24:23.210
bypass this local firewall and found[br]several ways of extracting it. And there's
0:24:23.210,0:24:27.549
even four or five of them that even allow[br]JavaScript execution in a mail
0:24:27.549,0:24:32.990
client. I mean come on this is really[br]weird. So basically 40 of 47 clients have
0:24:32.990,0:24:37.150
back channels that require no user[br]interaction at all. And now we went out
0:24:37.150,0:24:42.750
and tried to think about how can we[br]exfiltrate plain text over it. And this
0:24:42.750,0:24:48.809
is the final table the final result[br]table for S/MIME and it looks pretty
0:24:48.809,0:24:54.260
grim, right? So the red ones means it's[br]vulnerable. That means we could exfiltrate
0:24:54.260,0:24:59.539
plain text successfully. The ones with a[br]dash they don't support S/MIME and Claws
0:24:59.539,0:25:04.049
and Mutt we just didn't find any [br]remote connection there.
0:25:04.049,0:25:08.460
Okay. Which is good. Which is good. Yeah.[br]That's a round of applause. Right.
0:25:08.460,0:25:12.660
applause
0:25:12.660,0:25:17.500
So I didn't say what S in S/MIME means.[br]It actually means super. So it's super
0:25:17.500,0:25:23.270
MIME. I don't know. Is it Super MIME? And[br]basically his kryptonite. You know the the
0:25:23.270,0:25:28.710
super villan of Super MIME is HTML. Right.[br]You could say this. So S/MIME is broken
0:25:28.710,0:25:34.070
by HTML and it's a very annoying [br]kryptonite because it jumps you
0:25:34.070,0:25:41.560
know like it's ugly colors. Now this is my[br]Thunderbird that I have on my Mac at home.
0:25:41.560,0:25:46.090
So this is like something that I recorded[br]two days ago or so. And here I want to try
0:25:46.090,0:25:52.940
to show you a way of exfiltrading the data[br]without using HTML. So HTML here is
0:25:52.940,0:25:59.030
disabled. This is the message that we want[br]to break. And here we see the same message
0:25:59.030,0:26:03.770
where we just changed, using[br]gadgeting, we just changed the URL.
0:26:03.770,0:26:10.210
So in Thunderbird when you disable HTML[br]it will still highlight the links and when
0:26:10.210,0:26:17.360
you click on it you're gonna exfiltrate[br]plain text, right. So we require a little
0:26:17.360,0:26:23.720
bit of user interaction but we can[br]basically change a S/MIME ciphertext in a
0:26:23.720,0:26:28.230
way that it will contain links and when[br]you click a single link you will lose your
0:26:28.230,0:26:34.000
your plain text. It's just a single click[br]on it and the thing here is - I mean this
0:26:34.000,0:26:38.401
is not a zero day in e-mail client, right?[br]You just can't do anything about it.
0:26:38.401,0:26:45.919
That's the problem. Okay. So people said [br]okay so efail - just disable HTML and then
0:26:45.919,0:26:51.600
you'll be fine. But the problem here is[br]basically efail should work with any
0:26:51.600,0:26:56.789
format that supports external connections.[br]So as soon as you have a file format for
0:26:56.789,0:27:01.740
example that supports external connections[br]like PDF here, right? This is a PDF. When
0:27:01.740,0:27:05.870
you click on it it will warn you and will[br]say "Do you really want to make a
0:27:05.870,0:27:12.170
connection to this domain?" And if you[br]click "yes" you will do a connection there,
0:27:12.170,0:27:18.281
right? And when you look at the how[br]the URL is encoded in the PDF when you
0:27:18.281,0:27:23.090
open the PDF in an hex editor you see it's[br]just a string just like HTML,
0:27:23.090,0:27:27.720
basically, right? So we could in theory[br]use this as well. So you could change and
0:27:27.720,0:27:32.409
S/MIME e-mail that it contains a PDF[br]attachment and when you click the PDF
0:27:32.409,0:27:37.030
attachment it will exfiltrate. With no[br]user interaction, it works with with
0:27:37.030,0:27:42.700
Microsoft Word for example. So that's a[br]doc file and doc files allow external
0:27:42.700,0:27:50.850
images that will load. It has no user[br]interaction at all, so you just open it and
0:27:50.850,0:27:55.059
the request will happen and the only[br]problem that we're having here is it's not
0:27:55.059,0:27:59.809
an ASCII URL, it's a Unicode URL. So I'm[br]not sure whether this works with
0:27:59.809,0:28:05.620
exfiltration but hey no user interaction,[br]right? And. Now you could say "Okay PDF,
0:28:05.620,0:28:10.221
Microsoft Word. That's very bad." - The same[br]works in in LibreOffice and it's not a
0:28:10.221,0:28:19.510
bug in the viewers, right? It's a basic[br]feature that has been in these standards
0:28:19.510,0:28:23.150
forever, right? So it's a thing that will[br]be supported. It's not a zero day
0:28:23.150,0:28:28.350
vulnerability in these viewers. It's just[br]the file format support it, so you can
0:28:28.350,0:28:34.000
abuse it. If you have some time: here's a[br]challenge for you. If someone is able to
0:28:34.000,0:28:42.780
make a successful demo for exfiltrating an[br]S/MIME e-mail using a PDF or a doc file for
0:28:42.780,0:28:49.010
example you will get a crate of Club Mate[br]and some efail swag, if you want to?
0:28:49.010,0:28:56.150
OK. So what happened after we disclosed[br]it. Obviously we disclosed it to all the
0:28:56.150,0:29:00.780
manufacturers and so on. And there's an[br]S/MIME draft of a new RFC. So there's a
0:29:00.780,0:29:05.299
working group and they already[br]massaged the countermeasures into the
0:29:05.299,0:29:11.110
current RFC draft. So for example to[br]counter the CBC gadget attack they say: use
0:29:11.110,0:29:19.895
a GCM which is not right now in the in the[br]current RFC but in a draft it's already in.
0:29:19.895,0:29:22.140
And so they're referencing[br]the paper and they're saying:
0:29:22.140,0:29:26.700
"OK you need to do this and do this as[br]quickly as possible." And the second Efail
0:29:26.700,0:29:32.820
attack which I'll talk about very soon is[br]also mitigated in this in this RFC draft.
0:29:32.820,0:29:39.030
OK. So S/MIME was pretty much broken. And[br]you can just try to convince your e-mail
0:29:39.030,0:29:45.790
client not to do any external connections.[br]OK. That's all you have. Which at least,
0:29:45.790,0:29:51.720
I mean, for cryptographer this means[br]broken, OK? When you have to rely
0:29:51.720,0:29:56.429
on the viewer not making any connections,[br]the cryptography is broken. So what are
0:29:56.429,0:30:02.310
the changes to OpenPGP because there are[br]substantial differences to to OpenPGP.
0:30:02.310,0:30:08.570
So first of all PGP uses a variation of the[br]CFB-mode. It's not CBC-mode but CFB-mode.
0:30:08.570,0:30:15.240
And they have pretty similar, they are[br]very similar. So I won't show it here,
0:30:15.240,0:30:19.860
if you are looking for the details, please[br]look at the paper, but it's very similar.
0:30:19.860,0:30:25.110
We can also flip bits and we also have[br]these chunk bits in the middle and so on.
0:30:25.110,0:30:29.590
What really caused a lot of headaches is[br]the plain text compression. So that means
0:30:29.590,0:30:37.580
in OpenPGP you don't encrypt directly the[br]plain text but you deflate it
0:30:37.580,0:30:42.010
before you encrypt it and that makes it[br]very hard to guess plain text bytes, because
0:30:42.010,0:30:47.340
for our attack to work we need to guess plain[br]text bytes and when we know plain text
0:30:47.340,0:30:52.990
certain parts of the plain text but it's[br]deflated we have a problem. Okay? And what
0:30:52.990,0:30:57.520
is also the most important thing is that[br]OpenPGP defines a modification
0:30:57.520,0:31:02.340
detection code, which is basically this is[br]the message here. And the modification
0:31:02.340,0:31:07.900
detection code is a hash of the message[br]appended at the plain text and
0:31:07.900,0:31:17.919
then encrypted. Okay? Which should detect[br]plain text modifications. Now
0:31:17.919,0:31:25.190
how does the OpenPGP standard say how to[br]deal with broken MDCs when an MDC is not
0:31:25.190,0:31:29.320
valid. Well, they say an implementation[br]must treat an MDC failure as a security
0:31:29.320,0:31:34.470
problem, but they don't say what is a[br]security problem. What do you need to do
0:31:34.470,0:31:39.750
then. And the implementation may allow the[br]user access to the erroneous data. So the
0:31:39.750,0:31:44.049
modified data may be passed on to the[br]e-mail clients.
0:31:44.049,0:31:49.840
And basically we tried to do this, right?[br]But before we go there we looked at how
0:31:49.840,0:31:53.730
many keys on the public key servers[br]support MDCs at all.
0:31:53.730,0:32:01.010
So MDC is a feature that came to OpenPGP[br]in the early 2000s and before that it
0:32:01.010,0:32:05.390
wasn't possible to use it. And so[br]therefore to make this to make the change
0:32:05.390,0:32:11.730
from software that doesn't use MDC versus[br]software that that does use MDC they
0:32:11.730,0:32:17.580
encoded in the key whether you support MDC[br]or not. And here you see those keys that
0:32:17.580,0:32:22.000
were generated in 2000 they don't support[br]MDCs and the green ones - they support
0:32:22.000,0:32:30.710
it. But, the problem is, when you accumulate[br]all the valid keys in PGP that don't
0:32:30.710,0:32:37.190
support MDCs we still see that at the key[br]servers right now in 2017 we have
0:32:37.190,0:32:42.289
something like one point seven million of[br]the keys that don't support MDC. So when I
0:32:42.289,0:32:48.560
sent an email to one of these people my[br]implementation will not use an MDC, or
0:32:48.560,0:32:55.330
right? They - yeah I'll come to this later.[br]So we thought about okay how
0:32:55.330,0:33:00.070
can we make a structured analysis how the[br]MDC is treated with. The OpenPGP standard
0:33:00.070,0:33:05.419
is not clear what to do with it. And so[br]we have three test cases. First of all, we
0:33:05.419,0:33:10.909
try to strip the MDC. So we just use this[br]encrypted packet here and strip off at the
0:33:10.909,0:33:17.039
end. We just say OK it's incorrect, right?[br]So we make our modification in the
0:33:17.039,0:33:24.080
plain text and see whether they will detect[br]this error or we could also do this
0:33:24.080,0:33:29.230
downgrade from the packet type that[br]supports MDC to the old packet type that
0:33:29.230,0:33:34.840
does not support MDC, right? And when we[br]check this, especially with the most widely
0:33:34.840,0:33:40.260
used clients we saw that Thunderbird and[br]Enigmail and Apple Mail and GPG tools they
0:33:40.260,0:33:46.070
basically ignored the MDC and that was the[br]reason why we didn't see the MDC as very
0:33:46.070,0:33:51.670
important because in our test systems it[br]wasn't just treated, OK?
0:33:51.670,0:33:57.700
Now what are the Efail related changes[br]to OpenPGP. And we're talking about the
0:33:57.700,0:34:02.610
changes that were done after we[br]disclosed this to them.
0:34:02.610,0:34:05.640
First of all they made something that is[br]very important.
0:34:05.640,0:34:11.090
They say that the packet type and PGP that[br]does not support MDC is now obsolete. So
0:34:11.090,0:34:16.220
you must not use this packet type anymore.[br]You must ignore it. Which also means that
0:34:16.220,0:34:21.520
when you have used non MDC messages in[br]your mailbox you will not be able to open
0:34:21.520,0:34:28.340
them anymore, OK? Yeah. That's a[br]problem. Then they also said: "OK, what
0:34:28.340,0:34:33.860
is supposed to happen when the MDC[br]was wrong?" And this is the text that we
0:34:33.860,0:34:38.360
have already seen where we said "the[br]implementation may allow the user access
0:34:38.360,0:34:43.240
to the erroneous data" and they changed[br]this in the current draft to "the
0:34:43.240,0:34:48.280
implementation should not allow the user[br]to process the erroneous data." Right? They
0:34:48.280,0:34:53.190
must still warn the user. And so on and so[br]on. But it should not allow the user, which
0:34:53.190,0:35:02.410
is good. That's a good change. So this was[br]the - this MDC check is a bit troublesome
0:35:02.410,0:35:08.450
because it's right at the end of the[br]plain text, so you can only check the MDC
0:35:08.450,0:35:13.250
when you have fully decrypted the message[br]which means when you have a large e-mail
0:35:13.250,0:35:18.510
or a large back-up or so you have to fully[br]decrypt it and afterwards only you can tell
0:35:18.510,0:35:24.430
whether it was valid or not. And the[br]solution of GnuPG is that it will just
0:35:24.430,0:35:30.619
stream - while it decrypts it will stream[br]the data to to the e-mail client and
0:35:30.619,0:35:34.700
afterwards tell it whether it's supposed[br]to use it or not, OK? So here's your
0:35:34.700,0:35:39.891
email, here's your e-mail, here's your - Oh no![br]You must not use it, please forget it, right?
0:35:39.891,0:35:44.980
Which is not fine. This is not a safe way of[br]doing it. So the current OpenPGP draft,
0:35:44.980,0:35:48.690
before Efail, before we did the[br]disclosure already supported something
0:35:48.690,0:35:53.520
that they called chunking. So they not[br]only have an MDC some kind of a MAC at the
0:35:53.520,0:35:57.800
end of the plain text, but they chunk it[br]into more chunks and each of these
0:35:57.800,0:36:04.670
has a MAC - a real MAC - which is much better[br]because, right? You can authenticate chunks
0:36:04.670,0:36:13.660
and cache it before you give it to the[br]app. The problem is that the standard says
0:36:13.660,0:36:20.920
that 120MB is like a good chunk size[br]which is far too big, right? Far too big.
0:36:20.920,0:36:26.370
And when we look at the Efail related[br]changes to GnuPG. So for example MDCs
0:36:26.370,0:36:31.541
where they used to be warnings. So when[br]GnuPG was detecting that an MDC is not
0:36:31.541,0:36:37.589
there or it's wrong, they would just warn[br]it but it would still print it out. GnuPG
0:36:37.589,0:36:45.260
now, like, fails it makes a hard failure now[br]and GnuPG now always uses the MDC
0:36:45.260,0:36:50.811
independently if the key denotes that[br]the receiver can use it or not. Which
0:36:50.811,0:36:54.650
is also very good but it is a breaking[br]change, rightß So when you have people that
0:36:54.650,0:36:58.290
send you PGP e-mails and you can't decrypt[br]them anymore you have to tell them that
0:36:58.290,0:37:05.630
they need to update GnuPG.[br]They also say that the default chunk size
0:37:05.630,0:37:11.599
is 120 megabyte which means they still[br]stream unauthenticated plaintext so they
0:37:11.599,0:37:17.960
missed this opportunity to make [br]this go away, which is a pity.
0:37:17.960,0:37:24.380
Okay. What is not answered neither by[br]S/MIME nor by PGP: How to deal with past
0:37:24.380,0:37:28.150
e-mails? So, basically all the emails that[br]you're sending in S/MIME encrypted right
0:37:28.150,0:37:34.690
now are insecure and the old ones that[br]don't use MDC in PGP they are also not
0:37:34.690,0:37:39.480
secure and nobody talks about what's [br]supposed to happen with them, right?
0:37:39.480,0:37:43.920
Okay, that was the interesting attack. That
0:37:43.920,0:37:46.790
was the one that was really[br]cryptographically involving,
0:37:46.790,0:37:51.130
that required changes to the standards and[br]so on. Now let's look at something that's
0:37:51.130,0:37:56.790
a bit more silly. Okay, so we have Alice[br]writes an e-mail to Bob, we encrypt it and
0:37:56.790,0:38:02.730
send it off to Bob. Now here we have the[br]original e-mail and now Eve composes an
0:38:02.730,0:38:08.680
attack e-mail. And it somehow gained access[br]to the PGP ciphertext, it also works for
0:38:08.680,0:38:13.140
S/MIME, right, it's independent. It's a[br]vulnerability in the in the mail clients.
0:38:13.140,0:38:18.349
And now we don't change the ciphertext we[br]just surround it with other MIME parts
0:38:18.349,0:38:24.310
that are of type HTML and that exfiltrated[br]the same as we did before only that we
0:38:24.310,0:38:28.910
don't need to change the [br]ciphertext at all, right?
0:38:28.910,0:38:34.109
So basically when this is decrypted it[br]will be replaced with a plain text in
0:38:34.109,0:38:38.950
place and then it will be merged into one[br]document. And now I have to tell you
0:38:38.950,0:38:44.840
something that many people don't seem to[br]know. All mail clients, except mutt, they
0:38:44.840,0:38:51.800
use HTML to view emails. So even when you[br]disable HTML it basically means that they
0:38:51.800,0:38:57.531
will use incoming HTML e-mails, parse[br]them, transform them into something that
0:38:57.531,0:39:04.450
looks like ASCII and display this in HTML.[br]Okay. So, right? There is no such thing as
0:39:04.450,0:39:10.440
ASCII e-mails with most of the clients. So[br]but here now you have one HTML document
0:39:10.440,0:39:15.990
which basically means the same, it will[br]exfiltrate and very easy. Okay? So let's
0:39:15.990,0:39:22.400
look here and on this video here we have[br]we create one ciphertext we encrypt it. We
0:39:22.400,0:39:29.230
use Apple Mail because this was one of the[br]two vulnerable clients and we just open this
0:39:29.230,0:39:36.630
email in order to view the PGP ciphertext,[br]right? We look at the raw code of the
0:39:36.630,0:39:45.360
ciphertext, raw source and we scroll down[br]and there we see there's the PGP message,
0:39:45.360,0:39:52.530
OK? Now in the next minute Eve somehow[br]gained access to this ciphertext and it
0:39:52.530,0:40:01.310
will compose a attacker email which is[br]hidden in a python program that we just
0:40:01.310,0:40:06.140
use to generate an e-mail, so this[br]happened now in the background, you will
0:40:06.140,0:40:13.910
see an e-mail is incoming. Here we[br]just open the access log for this and when
0:40:13.910,0:40:20.690
we click on it, right at this time, it will[br]be exfiltrated. Okay. So very easy attack,
0:40:20.690,0:40:24.950
anyone can do this, you don't need to know[br]anything about cryptography you only need
0:40:24.950,0:40:28.970
to understand a little bit of HTML and a[br]little bit of MIME and you can execute
0:40:28.970,0:40:37.119
this. You know what's worse than this? How[br]about we just exfiltrate many e-mails with
0:40:37.119,0:40:42.050
a single attack e-mail because we could[br]basically use - here we open an image,
0:40:42.050,0:40:46.700
here's the ciphertext. Here would close[br]it. Then we open another image. Here's the
0:40:46.700,0:40:51.680
second ciphertext. Then we close it. Then[br]we open a third one and so on and so on.
0:40:51.680,0:40:56.910
And what you see here, on the left hand[br]side you see there's 100 ciphertext packed
0:40:56.910,0:41:02.630
into one e-mail that is sent to this[br]client. I blurred this because I used 100
0:41:02.630,0:41:08.800
GPG e-mails that I sent, right? I didn't[br]want to show them to you. Now this takes
0:41:08.800,0:41:13.050
some time. Now it's like decrypting,[br]decrypting, decrypting, decrypting. And when
0:41:13.050,0:41:17.580
you look at the terminal on the left side[br]you see 100 e-mails getting exfiltated,
0:41:17.580,0:41:23.599
right? Automatically simply by opening a[br]single email. Okay this is horrifying.
0:41:23.599,0:41:30.700
Applause
0:41:30.700,0:41:34.839
And when I say horrifying I'm really[br]literally mean: this is horrifying. So we
0:41:34.839,0:41:40.099
were like afraid OK when we disclose this[br]then people will start attacking this
0:41:40.099,0:41:48.410
within the hour or so, OK? And so we[br]disclosed this in early 2018. End of 2017,
0:41:48.410,0:41:57.010
early 2018. And in May 2018 we had already[br]shifted the disclosure date twice and in
0:41:57.010,0:42:01.680
May we said OK we won't shift this[br]anymore. And so therefore we said OK we go
0:42:01.680,0:42:06.309
online but we want to make a[br]preannouncement. We want to
0:42:06.309,0:42:11.690
warn the people that if you use [br]PGP or S/MIME for very sensitive
0:42:11.690,0:42:17.000
communication you should disable it in[br]your e-mail client for now. These are the
0:42:17.000,0:42:22.720
original tweets that we sent and we said: [br]OK, In a day, OK, when you have done this
0:42:22.720,0:42:27.050
then we will disclose everything, OK? We[br]will go online with the paper and
0:42:27.050,0:42:33.020
everything. And now I mean people started[br]talking about it and then the GnuPG people
0:42:33.020,0:42:37.950
started tweeting and they basically broke[br]the embargo. So they told OK the attack is
0:42:37.950,0:42:41.310
working like this. First you do this and[br]then you do that and then you do that and
0:42:41.310,0:42:45.160
they were blabbing and so on and then they[br]sent it, which is annoying, but then they
0:42:45.160,0:42:49.780
sent this. So they said know that new[br]GnuPG team was not contacted by them in
0:42:49.780,0:42:55.700
advance. And this, this really, OK? Then[br]it got really hot. Okay.
0:42:55.700,0:43:00.380
This is not true. I will show you later,[br]but I mean this tipped off almost anyone
0:43:00.380,0:43:06.160
in the INFOSEC community. And we got hate[br]e-mails and yeah people were really mad
0:43:06.160,0:43:10.200
with them, I posted "We did contact them."[br]and this is like the, these are the
0:43:10.200,0:43:13.820
original dates when I talked with Werner[br]Koch which is the main developer of of
0:43:13.820,0:43:18.150
GnuPG. But it was too late. I mean they[br]they recognized that they said: "Oh yeah, oh
0:43:18.150,0:43:25.380
I forgot!" Right? That they sent this paper[br]here. That writes EFAIL with our names and
0:43:25.380,0:43:31.430
a date and an embargo and so on and so on.[br]And they said they forgot it, OK? But I
0:43:31.430,0:43:37.180
mean we lost at this point, OK? People[br]were hating us. I was called a murderer.
0:43:37.180,0:43:41.290
And and so on and so on and so it was[br]really, really weird. If you're interested
0:43:41.290,0:43:45.150
of how things worked, right, this is an[br]independent summary of the disclosure
0:43:45.150,0:43:50.790
timeline from Thomas Ptacek which is not[br]involved with us at all we have never met
0:43:50.790,0:43:55.190
him, but who was so kind to just compile[br]this just from public information that are
0:43:55.190,0:44:01.590
really reliable.[br]So and then something happened that
0:44:01.590,0:44:07.320
we what we could foresee. People were[br]finding - like there were some patches -
0:44:07.320,0:44:12.130
and I told you already that we saw[br]that these patches are not sufficient.
0:44:12.130,0:44:18.630
And two days later people came up with new[br]style of attacks, new EFAIL attacks and
0:44:18.630,0:44:23.040
this was Hanno who found something. So he[br]said I found a trivial bypass EFAIL is
0:44:23.040,0:44:27.660
still exploitable with the latest Enigmail[br]and Thunderbird - that is three days after
0:44:27.660,0:44:32.030
we did the disclosure and he responsibly[br]disclosed this and so on and so on. So
0:44:32.030,0:44:37.460
everything is fine. Micah Lee, from The[br]Intercept, also developed a proof of
0:44:37.460,0:44:43.080
concept exploit that works against Apple[br]Mail and GPG tools also 2 or 3 days later.
0:44:43.080,0:44:48.030
So we were right, right? So people were[br]finding ways to circumvent the fixes that
0:44:48.030,0:44:54.780
were in there. But still I mean, OK, media[br]was blowing up, OK? And we didn't actually
0:44:54.780,0:45:01.849
understand what was really going on there.[br]But you have to know I mean PGP is like,
0:45:01.849,0:45:07.210
one of the main users of PHP, eh of PGP is[br]journalists, right.
0:45:07.210,0:45:11.130
So and they basically, I mean you show[br]it to them look that's the attack and they
0:45:11.130,0:45:16.690
will like what? That's how easy it is? And[br]that's what you see in the press I guess.
0:45:16.690,0:45:23.050
So what are the lessons learned from the[br]disclosure. So first of all: people kept
0:45:23.050,0:45:27.119
complaining, I mean people kept[br]complaining to us that we didn't stick to
0:45:27.119,0:45:32.310
the 90 day disclosure deadline. So[br]we had more than 200 days disclosure and
0:45:32.310,0:45:36.500
we postponed it and so on and so on. And[br]in the aftermath it didn't make sense
0:45:36.500,0:45:40.680
because we were postponing and postponing[br]it and there were still no reliable fixes.
0:45:40.680,0:45:43.910
So we should have stuck to the 90 day[br]disclosure deadline because after we
0:45:43.910,0:45:48.050
disclosed it they were in a rush. They[br]released patches and stuff like, you know?
0:45:48.050,0:45:54.190
So it was, yeah. Be careful with[br]disclosure preannouncements. The problem
0:45:54.190,0:46:00.861
here is people will speculate about the[br]details. You know, because when you say: "OK
0:46:00.861,0:46:04.650
we'll disclose something tomorrow but[br]we're not going to speak today" - then
0:46:04.650,0:46:08.839
journalists will speak to some random[br]people, right? That they just get their
0:46:08.839,0:46:14.390
hands on and they will just try to guess[br]what it could be. And this means they will
0:46:14.390,0:46:19.700
underrate the risk or they will overrate[br]the risk. Underrate the risk is just
0:46:19.700,0:46:23.540
disable external images, loading external[br]images, then you're fine. That is
0:46:23.540,0:46:30.240
underrating and overrating is like: "OK, PGP[br]is broken, forever", right? Which is not
0:46:30.240,0:46:34.510
the case. And they will spread this false[br]information and you still see this out
0:46:34.510,0:46:40.630
there, right? It's documented. People have[br]issued like papers and so on and so on
0:46:40.630,0:46:45.320
with wrong information, provably wrong[br]information. Which is bad and so these
0:46:45.320,0:46:48.480
disclosure preannouncements are bad[br]because you're not in control of the
0:46:48.480,0:46:53.040
communication anymore. That's very bad.[br]And controlling information flow really is
0:46:53.040,0:46:57.200
key after you do the disclosure because[br]otherwise you get the wrong story out and
0:46:57.200,0:47:05.810
this this doesn't help at all. Okay. Let's[br]look at the last attack, and we call this
0:47:05.810,0:47:10.300
reply to attacker.[br]And I have to give credit to the people of
0:47:10.300,0:47:16.730
Cure53, which also found this bug or a[br]similar very similar version of this bug
0:47:16.730,0:47:20.859
as well and disclosed it. But they were[br]first to disclose it so credit goes to
0:47:20.859,0:47:27.270
them, OK? Here, the attacker scenario is[br]I get an e-mail from some person which
0:47:27.270,0:47:32.280
makes sense. It's a benign e-mail. Okay.[br]It doesn't look bad at all. And a person
0:47:32.280,0:47:37.051
wants to trick me to answer this e-mail.[br]So this is the e-mail that I get. There's
0:47:37.051,0:47:42.940
some footer here and stuff like that. And[br]now we look in the video, it's an old
0:47:42.940,0:47:51.000
version of Mail that we use here. Right.[br]This is the e-mail. We just - and I answer
0:47:51.000,0:47:54.640
it, right? Because people were asking[br]me for an appointment they want to
0:47:54.640,0:47:58.730
meet me and I was like yeah sure after my[br]talk let's just meet. And this is the
0:47:58.730,0:48:05.000
attacker e-mail that the attackers opened[br]and when you look closely down here you'll
0:48:05.000,0:48:10.790
see secret stuff here that shouldn't be in[br]there and that I didn't send actually.
0:48:10.790,0:48:17.190
Let's look at the plain text of this[br]e-mail and the source code of this e-mail.
0:48:17.190,0:48:23.690
And when you scroll down you see it's a[br]mix of just a normal, just a normal
0:48:23.690,0:48:28.330
e-mail, benign e-mail. And down here you[br]find a ciphertext it can be S/MIME it can
0:48:28.330,0:48:35.270
be PGP. It doesn't really matter. And[br]what's happening now is:
0:48:35.270,0:48:39.700
I get this e-mail, this here will be[br]decrypted from my mail client and I don't
0:48:39.700,0:48:44.260
see it because I won't scroll down. I'm a[br]lazy person I'm a top poster. Right, now
0:48:44.260,0:48:50.180
you can go boo and so on, OK. But still I[br]mean top posting is considered evil here.
0:48:50.180,0:48:55.250
Because I basically - the attacker was[br]sending me an e-mail where ciphertext was
0:48:55.250,0:48:59.940
hidden in there that my e-mail client was[br]decrypting and I was replying to this
0:48:59.940,0:49:04.200
e-mail sending the attacker the actual[br]plain text that I just decrypted, without
0:49:04.200,0:49:10.530
knowing it. Okay that's silly. Okay. Come[br]on. That's really silly. Okay. What are
0:49:10.530,0:49:16.099
you supposed to do now. What are the[br]things that you should do. And the
0:49:16.099,0:49:20.829
important question here is you should ask[br]yourself are you targeted by motivated
0:49:20.829,0:49:23.310
attackers?[br]And a motivated attacker is not
0:49:23.310,0:49:29.230
necessarily the NSA or so, right? It can[br]be just, I don't know, Cybercrime people or
0:49:29.230,0:49:35.359
so. I mean we we basically came up with[br]these attacks with 8 people abd the better
0:49:35.359,0:49:40.270
part of a year. Which is not you know,[br]which is a lot of research actually but
0:49:40.270,0:49:44.521
it's not like comparable to a nation[br]state. Right. So if you're targeted by a
0:49:44.521,0:49:50.420
motivated attacker and if you say yeah you[br]are probably targeted by motivated
0:49:50.420,0:49:55.150
attackers then avoid e-mail in total.[br]E-mail is not made for secure
0:49:55.150,0:50:01.990
communication. Okay. If you can't avoid it[br]and there's people who can't avoid using
0:50:01.990,0:50:06.790
e-mail they can't just use signal or any[br]other chat client, then definitely use
0:50:06.790,0:50:15.000
OpenPGP and encrypt and decrypt outside of[br]the mail client. If you are probably not
0:50:15.000,0:50:21.960
targeted by motivated attackers, which is[br]most of you and I presume I would count to
0:50:21.960,0:50:27.510
the same people here, definitely prefer[br]OpenPGP over S/mime because S/mime remains
0:50:27.510,0:50:32.370
broken. Right, there is a standard coming[br]up which fixes most of the stuff. Disable
0:50:32.370,0:50:39.210
HTML for encrypted emails and this is like[br]not that easy. Note that most email
0:50:39.210,0:50:45.440
clients use HTML by default and it might[br]be okay if you fix it, the people that I
0:50:45.440,0:50:51.020
hear in the audience. But think of all the[br]people who are not here in this audience,
0:50:51.020,0:50:56.260
who are not technically versed and so on[br]and so on and they will not disable HTML,
0:50:56.260,0:51:00.800
right. So be careful with attachments[br]which is also very difficult, how can you
0:51:00.800,0:51:05.359
be careful with attachments. Right. This[br]is not very good. And don't top post,
0:51:05.359,0:51:12.589
don't cite text in a reply. Okay. That was[br]my talk. If you want to meet us afterwards
0:51:12.589,0:51:16.670
we're gonna go to the Chaos West. There's[br]a huge and lighted palm and we'll be there
0:51:16.670,0:51:23.020
if you have questions you can ask us[br]there. Thank you very much.
0:51:23.020,0:51:33.190
applause
0:51:33.190,0:51:37.780
Herald: Thanks a lot Sebastian, for this[br]interesting talk. We still have some time
0:51:37.780,0:51:41.960
for questions, so if you would like to ask[br]some questions to Sebastian then please
0:51:41.960,0:51:47.170
queue up behind the microphones, and[br]please try to be concise with your
0:51:47.170,0:51:51.319
question, and please get close to the[br]microphone, because the mixing Angel in
0:51:51.319,0:51:56.180
the back is able to make it quieter, but[br]hardly much louder, if your distance is
0:51:56.180,0:51:59.050
not right. So let's start with microphone[br]number 2.
0:51:59.050,0:52:05.950
Microphone 2: Test, test. Hello. I'm[br]actually tested the HTML exfiltrate you
0:52:05.950,0:52:18.589
described. But I found out, in[br]Thunderbird, the HTML parsing of
0:52:18.589,0:52:20.950
Thunderbird was actually helping against[br]the attack, because the word tags was just
0:52:20.950,0:52:25.910
disabled any possibility to exfiltrate the[br]message, because there were some div tag,
0:52:25.910,0:52:31.760
which is closing your image tag at every[br]point in time
0:52:31.760,0:52:37.140
Sebastian: Yeah, so, this is one of the[br]fixes, that they did. I mean it doesn't
0:52:37.140,0:52:40.990
help with the cryptography, but it makes[br]the exeltration a bit more difficult. If
0:52:40.990,0:52:45.890
you want to do the testing, try the[br]versions from before May this year.
0:52:45.890,0:52:48.942
Microphone 2: I did, I did with the old[br]versions.
0:52:48.942,0:52:51.680
Sebastian: We can talk afterwards if you[br]want, and I will show it to you.
0:52:51.680,0:52:56.690
Herald: We are streaming all the talks on[br]the Internet and we have people on the
0:52:56.690,0:53:00.210
internet that would like to ask a[br]question, so please a question from the
0:53:00.210,0:53:02.630
internet.[br]Signal Angel: Yeah, so there were actually
0:53:02.630,0:53:03.748
many questions in the direction of[br]problems with MIME standards. So, like,
0:53:03.748,0:53:05.040
what they were asking was basically[br]"Woudn't the exploitation be prevented, if
0:53:05.040,0:53:21.270
the email clients would handle the[br]standart correctly?"
0:53:21.270,0:53:26.790
Sebastian: Mhm, okay. So, I am not sure[br]whether they meant the MIME standards or
0:53:26.790,0:53:31.710
the S/MIME standards. So basically, the[br]MIME standards are that one to blame for
0:53:31.710,0:53:37.150
the direct exoltration attacks, were you[br]have multiple MIME-parts that are mixed
0:53:37.150,0:53:42.710
together, and the MIME standards don't[br]state explicitly how to do this. So they
0:53:42.710,0:53:48.339
don't have any rules of how to handle it,[br]and basically I think, as a rule of thumb,
0:53:48.339,0:53:53.500
when you try to be concise and complete[br]with implementing the MIME standard you
0:53:53.500,0:53:58.680
were vulnerable, and if you were just lazy[br]and just for example decrypted the first
0:53:58.680,0:54:04.110
MIME-part or so you were not vulnerable.[br]So, leaving out much of the stuff made you
0:54:04.110,0:54:08.810
more secure, which is weird.[br]Herald: Thank you for the answer. We have
0:54:08.810,0:54:12.680
another question in this hall, on[br]microphone number 6, and please remember
0:54:12.680,0:54:14.401
to be concise and get close to the[br]microphone.
0:54:14.401,0:54:16.740
Microphone 6: What do you see[br]Audio feedback loop
0:54:16.740,0:54:19.750
Microphone 6: Sorry.[br]Herald: Very good! We can always make it
0:54:19.750,0:54:20.750
quieter.[br]Applause
0:54:20.750,0:54:22.270
Herald: Laughing
0:54:22.270,0:54:25.970
Microphone 6: What do you see as a future
0:54:25.970,0:54:31.430
replacement to PGP for email encryption?[br]Sebastian: So actually, we brainstormed a
0:54:31.430,0:54:37.579
little, because PGP lacks many of the[br]modern properties, like forward secrecy
0:54:37.579,0:54:43.100
and stuff like this, but it turns out that[br]it's not very easy to do this. Especially
0:54:43.100,0:54:50.079
not with - when you don't want to do[br]changes to SMTP and IMAP. So, it's gonna
0:54:50.079,0:54:57.069
be difficult. It's gonna be difficult to[br]make it more secure than PGP, besides the
0:54:57.069,0:55:04.930
critisism that I already brought in. So,[br]E-Mail is not a very good protocol, or the
0:55:04.930,0:55:09.069
protocols that are built in E-Mail are not[br]a very good to build proper crypto on top
0:55:09.069,0:55:12.650
of it.[br]Herald: Thank you for this answer, so
0:55:12.650,0:55:17.560
maybe we need build something entirely new[br]from scratch. There is another question on
0:55:17.560,0:55:20.130
Microphone number 2, if I see this[br]correctly.
0:55:20.130,0:55:26.460
Microphone 2: So, do I understand it[br]correctly, it looks like there won't be a
0:55:26.460,0:55:33.050
fix for that multi part attacks, like[br]there is the normal plain text the
0:55:33.050,0:55:36.650
attacker writes, and then there is a[br]ciphertext, which my mail client decrypts;
0:55:36.650,0:55:40.650
there won't be a fix for that?[br]Sebastian: There is a fix, so the mail
0:55:40.650,0:55:44.839
clients are fixed, so that's because[br]that's a non-breaking fix, that's a good
0:55:44.839,0:55:49.089
thing here. So you can't fix S/MIME, for[br]example, because it would be a breaking
0:55:49.089,0:55:55.020
fix, but you could fix the email clients,[br]which was a lot of work, because MIME
0:55:55.020,0:55:59.190
parsers are very complex, but they fixed[br]it, so it's not supposed to work in
0:55:59.190,0:56:03.470
current mail clients anymore. The direct[br]exfiltration part.
0:56:03.470,0:56:08.380
Herald: So we still have quite some time[br]left and so I would like to have another
0:56:08.380,0:56:11.320
question form the internet.[br]Signal Angel: Yes, so one user asked
0:56:11.320,0:56:14.440
"would you recommend a better[br]path to integrate PGP into the E-Mail
0:56:14.440,0:56:27.150
clients instead of using extensions?"[br]Sebastian: Yea. I'm not a - I mean
0:56:27.150,0:56:31.920
I already talked about this that not many[br]people use PGP. And also not many people
0:56:31.920,0:56:36.750
use S/MIME.[br]I'm not sure, whether this will be
0:56:36.750,0:56:45.140
increased, when OpenPGP spilled into most[br]of the mail clients, because you could use
0:56:45.140,0:56:50.750
S/MIME, you know. As soon as S/MIME is[br]fixed it will be fine to use S/MIME, and
0:56:50.750,0:56:54.661
it's already in all the clients in there,[br]but not many people use it.
0:56:54.661,0:56:59.900
So it would be nice, if we could have it,[br]but I'm not sure whether it would have
0:56:59.900,0:57:06.910
much of an effect on the amount of people[br]who use it. Herald Angel: Thank you. And
0:57:06.910,0:57:10.849
we have another question from Microphone[br]number 7.
0:57:10.849,0:57:16.819
Microphone 7: Yes, hello. So I work with[br]journalists - here! here! here!
0:57:16.819,0:57:20.040
Herald Angel: There, in the very back.[br]Microphone 7: There, Hello. Hello.
0:57:20.040,0:57:21.599
Sebastian: Hi. Oh, yeah hi. How's it[br]going?
0:57:21.599,0:57:27.340
Microphone 7: So I work with journalists,[br]and May was very annoying, and I cannot
0:57:27.340,0:57:32.369
stress enough how important it is to - the[br]point you've made about communicating
0:57:32.369,0:57:33.440
around disclosure.[br]Sebastion: Yeah
0:57:33.440,0:57:37.470
Microphone 7: We were scrambling. I work[br]with about 200 journalists, who use PGP
0:57:37.470,0:57:40.710
daily, and we were scrambling for any bit[br]of information.
0:57:40.710,0:57:43.119
Sebastian: Yeah.[br]Microphone 7: What, what should we do? It
0:57:43.119,0:57:44.390
was, it was madness.[br]Sebastian: Yes.
0:57:44.390,0:57:49.250
Microphone 7: But I actually have a[br]question. The question is: Have you played
0:57:49.250,0:57:55.500
with Mailpile? I've read the, I've read[br]the paper. In the paper Mailpile, I think
0:57:55.500,0:58:01.700
I remember, was mentioned, and I vaguely[br]remember it was mentioned in a positive
0:58:01.700,0:58:07.619
light, but I just want to make sure, if[br]that's the right thing that I should get
0:58:07.619,0:58:10.230
from this paper.[br]Sebastian: I don't know it on the top of
0:58:10.230,0:58:15.910
my head, but if you come afterwards to[br]Chaos West we'll get out the paper and
0:58:15.910,0:58:18.690
look at the tests, and then we can answer[br]this question. Cool.
0:58:18.690,0:58:22.060
Microphone 7: Thank you.[br]Herald: Okay. We have another question on
0:58:22.060,0:58:27.569
the microphone number 6.[br]Microphone 6: So, I'd like to know if
0:58:27.569,0:58:37.050
there's any difference in the attack[br]surface, regarding OpenPGP, if plain,
0:58:37.050,0:58:47.190
like, plain PGP is used or PGP/MIME. For[br]example if you set your E-Mail client to
0:58:47.190,0:58:58.170
disallow decryption of inline PGP.[br]Sebastian: Yeah, that's a very good
0:58:58.170,0:59:02.320
question.[br]I mean the reply to attacker attack that I
0:59:02.320,0:59:08.230
just showed at the last. The Q53 people[br]came up with a version that worked with
0:59:08.230,0:59:15.729
inline PGP, and we showed that it's also[br]possible with PGP/MIME. So, I wouldn't say
0:59:15.729,0:59:22.170
- I mean, most of the people use PGP/MIME.[br]Inline PGP is not used anymore. The
0:59:22.170,0:59:27.280
problem is, when you don't decrypt PGP,[br]inline PGP, then you have a problem when
0:59:27.280,0:59:32.520
people use PGP at an external application.[br]They can't copy and paste the ciphertext
0:59:32.520,0:59:37.170
in there anymore, which is also very[br]annoying. And I also told you that it's, I
0:59:37.170,0:59:40.910
think it's a very good idea to do this[br]outside of the mail client, if you're in
0:59:40.910,0:59:47.590
a, if you face motivated attackers. So,[br]it's not that easy. it would be a breaking
0:59:47.590,0:59:50.380
change that wouldn't, maybe not be too[br]good.
0:59:50.380,0:59:54.250
Microphone 6: Okay. Thanks.[br]Sebastian: Okay.
0:59:54.250,0:59:58.660
Herald: Thanks a lot for this answer. I[br]think we are done with all the questions
0:59:58.660,1:00:03.330
from the hall. If you like to continue the[br]discussion with Sebastian Schinzel, you
1:00:03.330,1:00:09.151
may move yourself to the assembly of Chaos[br]West in the next hall in this direction.
1:00:09.151,1:00:11.980
And now please give a big round of[br]applause for Sebastian Schinzel and the
1:00:11.980,1:00:14.880
awesome team behind.[br]Applause
1:00:14.880,1:00:18.815
Outro plays
1:00:18.815,1:00:38.000
subtitles created by c3subtitles.de[br]in the year 2020. Join, and help us!