1 00:00:00,000 --> 00:00:18,070 *35C3 preroll music* 2 00:00:18,070 --> 00:00:24,070 Herald: The following talk is about email encryption. Who worries that their email 3 00:00:24,070 --> 00:00:32,800 encryption might be capable of being hacked or cracked? Worry not as far as I'm 4 00:00:32,800 --> 00:00:40,050 told it still is rather secure. But. And the but will be answered by Sebastian 5 00:00:40,050 --> 00:00:45,879 Schinzel who is one of the eight security researchers who uncovered the drama and 6 00:00:45,879 --> 00:00:54,829 the details behind e-fail. A recently occurred issue with OpenPGP and S/MIME 7 00:00:54,829 --> 00:00:59,600 in a lot of email clients. All the technical details he will dig into so 8 00:00:59,600 --> 00:01:03,339 please give a warm hand of applause for Sebastian Schinzel. 9 00:01:03,339 --> 00:01:09,850 *applause* 10 00:01:09,850 --> 00:01:15,080 Sebastian: So it's good to be back. Thank you everyone for coming. My name is 11 00:01:15,080 --> 00:01:22,080 Sebastian. It's my fourth talk here at the CCC. And the other talks that I did were 12 00:01:22,080 --> 00:01:27,260 also on encryption so I somehow like encryption and I like analyzing encryption 13 00:01:27,260 --> 00:01:31,320 and I like to break encryption. So I did a talk on TLS where we found an attack 14 00:01:31,320 --> 00:01:39,070 against TLS and against XML encryption for example. And I usually start my talk by 15 00:01:39,070 --> 00:01:45,030 asking Who's using this this specific technology, right? Because when you when 16 00:01:45,030 --> 00:01:49,710 you usually when you're analyzing or doing a talk about a communication protocol you 17 00:01:49,710 --> 00:01:57,144 ask the people who's using that and you know for e-mail it would be silly, right? 18 00:01:57,144 --> 00:02:00,200 Because, who's using e-mail. Every one of you is using e-mail. 19 00:02:00,200 --> 00:02:04,921 OK. Because I don't know. I mean when you started using the Internet like 20 00:02:04,921 --> 00:02:10,369 in the last 20 years or so usually the first thing that you do you dial in 21 00:02:10,369 --> 00:02:13,409 onto the Internet and you make yourself an e-mail address, right? 22 00:02:13,409 --> 00:02:20,980 So everyone has everyone uses e-mail. But let's take a look at how things work when 23 00:02:20,980 --> 00:02:25,359 when you send an email. So when you click in your email client when you when you 24 00:02:25,359 --> 00:02:30,329 compose an email and you click into your email client "Send". So the first thing is 25 00:02:30,329 --> 00:02:34,989 on one of your devices you're using the local network and there's a green arrow 26 00:02:34,989 --> 00:02:40,790 because it's under your control. So you can define by yourself how secure this 27 00:02:40,790 --> 00:02:45,560 link is gonna be. Then you use the next connection and the next connection will be 28 00:02:45,560 --> 00:02:50,437 to your SMTP server. And this is also a green arrow because it's under your control. 29 00:02:50,437 --> 00:02:53,344 Okay. You can control this and usually it's TLS. 30 00:02:53,344 --> 00:02:58,950 The same as valid for your IMAP folder because always when you send an 31 00:02:58,950 --> 00:03:07,180 email via SMTP you will upload a copy to your "sent" folder on IMAP and it uses TLS 32 00:03:07,180 --> 00:03:12,379 in most of the cases so therefore the arrow is green. The arrow is not that 33 00:03:12,379 --> 00:03:17,659 green anymore when it comes to the backup strategy for example an archiving strategy 34 00:03:17,659 --> 00:03:23,599 of your email provider which may be gmail or gmx for example or your company. OK. 35 00:03:23,599 --> 00:03:27,370 But you may have a chance to know the administrators and ask him whether they 36 00:03:27,370 --> 00:03:33,579 are doing a good job and stuff like that. You're also - it's not under your 37 00:03:33,579 --> 00:03:38,840 control where else your email is uploaded to. So for example in order to check it 38 00:03:38,840 --> 00:03:44,620 for antivirus or anti spam and stuff like that, right? So it gets uploaded to some 39 00:03:44,620 --> 00:03:50,389 cloud, right? Because you want to do a spam filtering and then it goes out to the 40 00:03:50,389 --> 00:03:54,200 Internet and you know we learned what's happening on the Internet. People are 41 00:03:54,200 --> 00:04:00,459 listening in on the Internet and we heard from Edward Snowden for example that many 42 00:04:00,459 --> 00:04:05,150 nation state actors and agencies are doing this as well they are listening into 43 00:04:05,150 --> 00:04:11,549 your e-mails or they at least try to. And then the arrows get red as soon as it hits 44 00:04:11,549 --> 00:04:16,431 the SMTP server of the receiver. Right. Because you don't really know whether they 45 00:04:16,431 --> 00:04:21,250 are using TLS, encryption in any case. You don't know whether they upload it to 46 00:04:21,250 --> 00:04:27,040 another antivirus vendor or so and then it gets uploaded to the IMAP folder to the 47 00:04:27,040 --> 00:04:31,990 inbox of the receiver where it gets archived again, right? There is a backup 48 00:04:31,990 --> 00:04:38,310 is being done and stuff like that, it's archived. And then finally the receiver of 49 00:04:38,310 --> 00:04:42,831 the e-mail has the ability to check his own email and retrieve the e-mail 50 00:04:42,831 --> 00:04:49,150 from his inbox. OK. So even if you know that the other person that you've just 51 00:04:49,150 --> 00:04:53,490 sent the e-mail to does a good job in securing it and uses encryption everywhere 52 00:04:53,490 --> 00:04:56,380 and so on and so on. You never know whether there's some 53 00:04:56,380 --> 00:05:01,780 attacker or so who has compromised the infrastructure and so on and so on. OK. 54 00:05:01,780 --> 00:05:06,790 And this problem multiplies. When you send an e-mail to multiple people 55 00:05:06,790 --> 00:05:11,140 because then all of a sudden the e-mail that you just sent, your e-mail, hits 56 00:05:11,140 --> 00:05:17,270 infrastructures of many other people. OK? So many people have access to this 57 00:05:17,270 --> 00:05:22,140 e-mail and this is the first thing that I want to - this is the first point that I 58 00:05:22,140 --> 00:05:27,430 want to make in this talk. People usually talk about their e-mail. It's my e-mail, 59 00:05:27,430 --> 00:05:31,960 you know? And when I run my own mail server it's going to be secure but this is not 60 00:05:31,960 --> 00:05:36,630 the case. I mean the the point of using e-mail is distributing it to your 61 00:05:36,630 --> 00:05:40,030 friends to your colleagues and so on and so on because we want to exchange. 62 00:05:40,030 --> 00:05:43,430 It's a communication method but the communication is archived so people 63 00:05:43,430 --> 00:05:52,120 archive this and so on and so on. So it's it's a mess basically. OK. So for the rest 64 00:05:52,120 --> 00:05:56,090 of this talk we need to have some assumption that someone has access to the 65 00:05:56,090 --> 00:06:02,091 e-mails. OK. Because right. We just learned that it's distributed. You're 66 00:06:02,091 --> 00:06:05,620 archiving your own e-mails in your IMAP folder and so on and so on I have the 67 00:06:05,620 --> 00:06:09,520 e-mails of the last 15 years or so in my in my IMAP folder and if someone gets 68 00:06:09,520 --> 00:06:14,940 access to it - right - boom. I have a problem. Okay. And in order to cope with 69 00:06:14,940 --> 00:06:19,090 this people came up with end-to-end encryption. And there's two competing 70 00:06:19,090 --> 00:06:28,180 standards out there. The first one is OpenPGP. It was first defined in 1991 from 71 00:06:28,180 --> 00:06:32,340 Phil Zimmermann invited it. And this was like this happened in the first crypto 72 00:06:32,340 --> 00:06:39,400 wars. So this is a very interesting story. And it's the most widely used e-mail 73 00:06:39,400 --> 00:06:42,940 clients they they support OpenPGP but only when you when you download the 74 00:06:42,940 --> 00:06:48,590 plug-in, OK? For S/MIME you usually have native support in most of the 75 00:06:48,590 --> 00:06:52,900 applications so you just get an S/MIME certificate and off you go. 76 00:06:52,900 --> 00:06:57,020 You can just use it and it just works out of the box but it's mostly used by 77 00:06:57,020 --> 00:07:01,530 corporate organizations and military for example right. Not so much by privacy 78 00:07:01,530 --> 00:07:06,700 advocates like OpenPGP. Now we can't measure very well how many 79 00:07:06,700 --> 00:07:11,230 people use S/MIME. We tried but there doesn't seem to be a public source where 80 00:07:11,230 --> 00:07:15,790 we can measure this but we can do it on PGP because PGP has key servers and you 81 00:07:15,790 --> 00:07:19,520 can upload your key there so that people can communicate with you in a secure 82 00:07:19,520 --> 00:07:26,150 manner. And this statistic here is the amount of new published public keys per 83 00:07:26,150 --> 00:07:32,920 month. And it started off very low in 1997. Then in 2003 we saw a constant rise 84 00:07:32,920 --> 00:07:39,600 until 2013 where we see a a spike here where it more than doubled. Does anyone 85 00:07:39,600 --> 00:07:43,330 know why we saw this spike in 2013? Someone in the audience: Snowden! 86 00:07:43,330 --> 00:07:48,560 Sebastian: Snowden right. Edward Snowden we had the Snowden revelations and Edward 87 00:07:48,560 --> 00:07:54,060 Snowden uses PGP to communicate with the journalists who did the actual, like, 88 00:07:54,060 --> 00:07:59,639 disclosure of the documents. And so we see this in the uploader keys so people use 89 00:07:59,639 --> 00:08:05,500 PGP much more. We also see this in the amount of daily users of Enigmail 90 00:08:05,500 --> 00:08:10,560 which is the plugin for Thunderbird. And you can extract this 91 00:08:10,560 --> 00:08:16,400 information and there we also see around 2013 we see a jump and it increased by 50 92 00:08:16,400 --> 00:08:21,140 percent or so something like this. So people use PGP, right? It's not that many 93 00:08:21,140 --> 00:08:25,210 when you compare it to how many people use e-mail a few hundred thousand is not that 94 00:08:25,210 --> 00:08:31,580 much but still it's a substantial number. The problem here is we know for a fact 95 00:08:31,580 --> 00:08:38,000 that in the last 20 years or so especially non-technical users are not able to use 96 00:08:38,000 --> 00:08:43,860 PGP in a secure manner. Okay. So we have the first paper from '99: "Why Johnny 97 00:08:43,860 --> 00:08:49,091 Can't encrypt" and then we have a follow up paper from 2006: "Why Johnny still 98 00:08:49,091 --> 00:08:54,700 can't encrypt", OK? So OK. Must've been better I hope and then in 2015 we 99 00:08:54,700 --> 00:09:00,460 have "why Johnny Still, Still can't encrypt". OK? so we have a long story 100 00:09:00,460 --> 00:09:06,170 where people try to use PGP but failed, OK? And this is not something that is 101 00:09:06,170 --> 00:09:13,310 inherent in an OpenPGP. We have the same papers for S/MIME where they said 102 00:09:13,310 --> 00:09:18,240 novice users - and where they confronted novice users with with S/MIME and they 103 00:09:18,240 --> 00:09:23,260 failed, basically. They weren't able to use it in a secure manner. Okay. 104 00:09:23,260 --> 00:09:29,240 So therefore in order to enable people to use PGP, especially PGP and S/MIME in a 105 00:09:29,240 --> 00:09:34,300 secure manner you have many tutorials out there. And this is a very interesting 106 00:09:34,300 --> 00:09:38,900 tutorial because it's the original video that Edward Snowden recorded in order to 107 00:09:38,900 --> 00:09:44,480 teach Glenn Greenwald how to use openPGP. It's still on Vimeo. The original video is 108 00:09:44,480 --> 00:09:49,330 still there. And what is interesting there is he doesn't recommend a plugin for an 109 00:09:49,330 --> 00:09:55,170 email client. He basically says just use web mail and use this PGP standalone 110 00:09:55,170 --> 00:10:00,460 application type your message there click encrypt and copy and paste the ciphertext 111 00:10:00,460 --> 00:10:06,040 into your web mail, OK? So there's no integration and others recommend for 112 00:10:06,040 --> 00:10:13,120 example Enigmail or GPGtools. Enigmail is the plugin for Thunderbird and GPGtools is 113 00:10:13,120 --> 00:10:18,390 the plug in for Apple mail, which means that most of them had HTML 114 00:10:18,390 --> 00:10:22,970 switched on which is an interesting fact. OK. For something that we are going to 115 00:10:22,970 --> 00:10:29,340 talk about later. So I thought about how can I do this talk. And this is how I came 116 00:10:29,340 --> 00:10:33,650 up with the agenda. So we start off with some attacks that are very I find pretty 117 00:10:33,650 --> 00:10:37,260 interesting. At least for an academic they are pretty interesting, and we slowly 118 00:10:37,260 --> 00:10:42,300 degrade to pretty silly attacks and you decide for yourself whether you would fall 119 00:10:42,300 --> 00:10:47,720 for it or not. I came to the conclusion that I would probably fall for them. OK, 120 00:10:47,720 --> 00:10:53,780 I lied. So we start off with something that is even worse than silly. So what is 121 00:10:53,780 --> 00:10:58,210 it what's the worst thing that can happen when you're sending an encrypted mail. 122 00:10:58,210 --> 00:11:00,570 Audience: You send your private key. 123 00:11:00,570 --> 00:11:03,690 Sebastian: if you send your private key there would be bad. What's even worse? 124 00:11:03,690 --> 00:11:06,290 Audience: You forget to encrypt. 125 00:11:06,290 --> 00:11:11,770 Sebastian: you send a plain text. Okay okay. So in 2014 there was a bug in 126 00:11:11,770 --> 00:11:16,210 Enigmail which is documented in their bug tracker. So basically you compose an e-mail 127 00:11:16,210 --> 00:11:19,860 you tell Enigmail to sign and encrypt it, and then you send it and it will be 128 00:11:19,860 --> 00:11:27,860 sent in plain text. Okay. Oh okay. This is not good. In 2017 Outlook did it much better 129 00:11:27,860 --> 00:11:32,710 because they did encrypt it but they packed the plain text along with the 130 00:11:32,710 --> 00:11:42,350 ciphertext. (Audience: laughing) Okay. Bad. And then in 2018 you may remember this is 131 00:11:42,350 --> 00:11:48,270 just a few months back or so Enigmail or pretty easy privacy. It's a plugin to 132 00:11:48,270 --> 00:11:52,660 Enigmail, so a plugin to a plugin that's actually used for novice users. It gave 133 00:11:52,660 --> 00:11:57,040 the feedback that the email that you're composing will be encrypted but it wasn't. 134 00:11:57,040 --> 00:12:04,529 Okay. And the good news here is: the e-mail attacks don't apply here because, 135 00:12:04,529 --> 00:12:10,230 OK, I mean, it's about I don't want to make fun of any developers. The point that I'm 136 00:12:10,230 --> 00:12:16,010 trying to make here is that email is a plaintext protocol and it's always very 137 00:12:16,010 --> 00:12:21,890 difficult to make a protocol that was made for plain text delivery - to make this 138 00:12:21,890 --> 00:12:26,040 encrypted. When you have a plaintext fallback you're into trouble. Okay. And we 139 00:12:26,040 --> 00:12:33,710 we saw the same basically with HTTP and HTTPS. OK. So HTTPS is like now secure but 140 00:12:33,710 --> 00:12:37,640 they hit the same issues right and browsers and so they were falling back to 141 00:12:37,640 --> 00:12:42,529 HTTP and so on and so on. So it's really really difficult. Now that we have this 142 00:12:42,529 --> 00:12:47,920 out of the way. Okay. We tried to look at the interesting interesting box and before 143 00:12:47,920 --> 00:12:53,580 we start I want to make a short introduction into how the cryptography in 144 00:12:53,580 --> 00:12:59,610 S/MIME and PGP work. And I just make one introduction because both are the same 145 00:12:59,610 --> 00:13:03,000 from the viewpoint of the attacks that I'm going to present. Okay. Both are very 146 00:13:03,000 --> 00:13:08,770 similar actually. So we start off by writing a message, m, this is here we 147 00:13:08,770 --> 00:13:13,760 generate a session key, s, that that's basically a random session key and we use 148 00:13:13,760 --> 00:13:19,780 this session key to encrypt the message and make a cipher text, c, and we use AES 149 00:13:19,780 --> 00:13:26,390 or triple DES for example any symmetric cipher will do here. 150 00:13:26,390 --> 00:13:31,910 Then we use this session key that we just generated and encrypt this with a public 151 00:13:31,910 --> 00:13:37,160 key of the recipient and we get a K and we pack this K into the message so everything 152 00:13:37,160 --> 00:13:43,040 will be packed into a message and sent off to the receiver. The receiver then 153 00:13:43,040 --> 00:13:49,050 obtains the encrypted email he starts extracting the ciphertext K and the 154 00:13:49,050 --> 00:13:56,490 ciphertext C. From K he decrypts s which is the session key, right? And with s he can 155 00:13:56,490 --> 00:14:02,580 decrypt the ciphertext C and retrieves m. And so both have the same message. Okay. 156 00:14:02,580 --> 00:14:06,670 So it's basically a hybrid encryption you use symmetric encryption for the actual 157 00:14:06,670 --> 00:14:11,740 encryption off the message and then asymmetric encryption to just encrypt this 158 00:14:11,740 --> 00:14:17,870 session key. Now, if you attended my previous talks I talk a lot about 159 00:14:17,870 --> 00:14:23,940 ciphertext malleability. So you make tiny changes to a cipher text and it will lead 160 00:14:23,940 --> 00:14:28,589 to predictable changes in the plaintext which is strange, right? So we would 161 00:14:28,589 --> 00:14:33,529 assume when we just flip a bit here somewhere, okay? Here's a bit that just 162 00:14:33,529 --> 00:14:37,470 flipped and where we decrypted we get something like this. Usually you would 163 00:14:37,470 --> 00:14:42,860 think OK. It's total garbage. Nothing sensible should come out of 164 00:14:42,860 --> 00:14:47,120 this but we see something like this. Most of the message is still intact. We just 165 00:14:47,120 --> 00:14:54,920 have a few randomly looking junk binary stuff in there and we see one changed 166 00:14:54,920 --> 00:14:59,850 character here. That used to be "email" and now it's "efail". Okay so there was 167 00:14:59,850 --> 00:15:04,240 just some bit flipping happening here. In order to understand this we need to 168 00:15:04,240 --> 00:15:08,990 introduce something that we called a mode of operation. AES or any other block 169 00:15:08,990 --> 00:15:14,910 cipher has the property that it uses blocks. In most cases it's 16 bytes. 170 00:15:14,910 --> 00:15:20,520 And when you want to encrypt more than 16 bytes you need to call AES multiple times 171 00:15:20,520 --> 00:15:25,470 and you split it into blocks and CBC is one way of connecting these ciphertext 172 00:15:25,470 --> 00:15:30,580 blocks so the decryption works like this. You have the first ciphertext block the 173 00:15:30,580 --> 00:15:36,839 second ciphertext block and the third ciphertext block. Only the second one is 174 00:15:36,839 --> 00:15:43,019 decrypted so C1 is decrypted using AES and your key for example. And the result here 175 00:15:43,019 --> 00:15:50,000 is not directly the plaintext but it will be XORed with C0 which will we would also 176 00:15:50,000 --> 00:15:55,470 call an initialization vector. Okay so whatever is written in here will be XORed 177 00:15:55,470 --> 00:16:00,550 on whatever comes out of this description and we get this plaintext here. Now when 178 00:16:00,550 --> 00:16:06,970 we flip a bit or when we change a certain byte in C0 we change whatever comes out 179 00:16:06,970 --> 00:16:11,930 here of the decryption and we will flip the same bit at the same position in 180 00:16:11,930 --> 00:16:18,891 the plaintext which is interesting because now when we say we use the original c0 and 181 00:16:18,891 --> 00:16:27,410 XOR it with p0. So when we XOR it when we XOR two times the same value we get 182 00:16:27,410 --> 00:16:33,870 basically a block of all zeros which is like a blank sheet of paper that we can 183 00:16:33,870 --> 00:16:38,570 write on and we call this thing - these two blocks here in combination - we call this a 184 00:16:38,570 --> 00:16:45,060 CBC gadget because we can reuse it as as much as we want. And when we now take a 185 00:16:45,060 --> 00:16:51,190 chosen ciphertext the nice thing is here we just XOR it - the chosen ciphertext on 186 00:16:51,190 --> 00:16:55,730 this initialization vector and it means that it will here result in a chosen 187 00:16:55,730 --> 00:17:00,640 ciphertext. So this requires that we know the value of 188 00:17:00,640 --> 00:17:06,870 p0. We need to guess this value of p0. And this is always true at least for S/MIME 189 00:17:06,870 --> 00:17:11,770 because all S/MIME emails start with a content type so we always know the first 190 00:17:11,770 --> 00:17:18,549 bytes. So this is valid. We can do this now. This was like the perfect 191 00:17:18,549 --> 00:17:23,949 scenario. It does have some drawbacks because when we tried to do the same for 192 00:17:23,949 --> 00:17:30,080 C1 we switch, we flip, a bit here then we flip a bit also here. But the decryption 193 00:17:30,080 --> 00:17:35,360 of C1 results in this random junk and we can't do anything about it. We don't know 194 00:17:35,360 --> 00:17:39,890 whatever will come out here and we can't control it. Okay we just have to deal with 195 00:17:39,890 --> 00:17:44,300 it. It's gonna be there when we use the CBC gadgets and we have to deal with it. 196 00:17:44,300 --> 00:17:49,480 We have to find a way to deal with it and now we can explain this behavior, you know? 197 00:17:49,480 --> 00:17:53,799 You remember this e-mail where we just flipped a single bit and we saw one block 198 00:17:53,799 --> 00:17:58,950 was destroyed basically. And then the other block we had like we can flip 199 00:17:58,950 --> 00:18:04,410 arbitrary bits. That's the explanation for it. Now how do you how do 200 00:18:04,410 --> 00:18:09,090 you deal with it. How should a proper crypto protocol deal with it. Usually you 201 00:18:09,090 --> 00:18:13,170 do something that is called a message authentication code. It's not a digital 202 00:18:13,170 --> 00:18:19,010 signature and message authentication code is something like a checksum a 203 00:18:19,010 --> 00:18:24,240 cryptographic checksum that is put right next to the 204 00:18:24,240 --> 00:18:28,170 encrypted message and that can be checked after decryption or for 205 00:18:28,170 --> 00:18:31,160 decryption. OK? The message authentication code is solely there to 206 00:18:31,160 --> 00:18:36,480 detect changes of a ciphertext. Digital signatures are different especially in the 207 00:18:36,480 --> 00:18:40,840 mail context because they're pretty much totally separate from 208 00:18:40,840 --> 00:18:47,460 the decryption part. So digital signatures are merely only used to display an icon 209 00:18:47,460 --> 00:18:55,710 for example for valid signature or invalid signature. And the problem here is a smart 210 00:18:55,710 --> 00:19:01,090 attacker can use a signed email and strip off the signature. Okay. We just strip off 211 00:19:01,090 --> 00:19:06,260 this part that we know there's a signature we can remove the signature and then this 212 00:19:06,260 --> 00:19:09,980 doesn't mean there will be an invalid signature but will get something like 213 00:19:09,980 --> 00:19:15,770 this. This is the icon in thunderbird for encrypted and not signed so we can simply 214 00:19:15,770 --> 00:19:21,970 strip off a signature and there's valid reasons to send an encrypted email without 215 00:19:21,970 --> 00:19:27,720 doing a digital signature on it, right? So we want to do both. So digital 216 00:19:27,720 --> 00:19:34,080 signatures won't prevent this attack. So how does S/MIME look like? 217 00:19:34,080 --> 00:19:39,170 Basically, I mean, most of you will have heard of MIME. MIME is like a standard 218 00:19:39,170 --> 00:19:45,310 that we use in emails anyway. Here we have an e-mail header. It looks very 219 00:19:45,310 --> 00:19:50,600 similar to HTTP. We have content type, colon, empty space, and then it's 220 00:19:50,600 --> 00:19:56,640 whatever is coming now for data. And then we have an e-mail body with envelope data 221 00:19:56,640 --> 00:20:01,040 and there we have the list of the of the encrypted session keys that this 222 00:20:01,040 --> 00:20:08,040 ciphertext was encrypted with. And after that we have the encrypted content info 223 00:20:08,040 --> 00:20:12,580 here. This part is the encrypted part where the actual message where the actual 224 00:20:12,580 --> 00:20:17,490 message lies. And now when you look closely and you squint you see there's no 225 00:20:17,490 --> 00:20:22,540 message authentication code and it's not because I left them out but because S/MIME 226 00:20:22,540 --> 00:20:26,669 doesn't define one. So S/MIME doesn't have a message authentication code which 227 00:20:26,669 --> 00:20:33,040 means it cannot detect bye the standard whether a message was changed - whether 228 00:20:33,040 --> 00:20:36,780 it was changed or not. So how can we attack this? 229 00:20:36,780 --> 00:20:41,590 How can we use it? I think you all have a feeling that this shouldn't work, OK? This 230 00:20:41,590 --> 00:20:46,950 is nothing that is supposed to work. This is the plain text that we want to 231 00:20:46,950 --> 00:20:51,210 exfiltrate and we only know the first block. We can pretty much always guess the 232 00:20:51,210 --> 00:20:56,380 first block because it's always content type: text/html or text/plain something 233 00:20:56,380 --> 00:21:03,960 like this. Now we can use this as a gadget here and write our arbitrary plain text. 234 00:21:03,960 --> 00:21:08,331 We have a random block and then chosen plain text. Then we copy it again. We 235 00:21:08,331 --> 00:21:12,780 again have a random block and some chosen plain text. Then we have a random block 236 00:21:12,780 --> 00:21:17,051 and a chosen plain text. Then we have a random block and a chosen plain text. Then 237 00:21:17,051 --> 00:21:23,780 we copy here the original ciphertext and we close this thing. And when you look 238 00:21:23,780 --> 00:21:28,120 closely again you'll see that we're building HTML here right. That's the base 239 00:21:28,120 --> 00:21:33,920 tag. That's an image tag. It uses a URL. That is not closed here. It will be closed 240 00:21:33,920 --> 00:21:40,490 down here. And this is effectively the URL. OK. A URL-path and will thus be 241 00:21:40,490 --> 00:21:45,200 exfiltrated. So when this XML is interpreted the actual plain text is sent 242 00:21:45,200 --> 00:21:51,750 to the server. And here we have an old Thunderbird. So that is a version of 243 00:21:51,750 --> 00:21:58,100 before May and before we did the disclosure. We first compose a message 244 00:21:58,100 --> 00:22:03,419 just to have some PGP ciphertext. This is a very secret message. And here we have 245 00:22:03,419 --> 00:22:09,850 the attack e-mail that is already prepared. And now it asks us 246 00:22:09,850 --> 00:22:13,820 "This remote content in here. What do you want to do?" And we just for the 247 00:22:13,820 --> 00:22:19,370 laughs just - like this - we just click it and we see always now when we select the 248 00:22:19,370 --> 00:22:27,320 message an HTTP request is done to this to this URL. And when we decode this - it 249 00:22:27,320 --> 00:22:32,330 looks pretty - it's encoded. But basically what we have here now you see here is the 250 00:22:32,330 --> 00:22:37,370 secret message and here is random junk. And here again is random junk, right? So 251 00:22:37,370 --> 00:22:43,400 it was successfully exfiltrated. This was the first proof of concept that we had. 252 00:22:43,400 --> 00:22:50,540 Right? And. Okay right? And so this works. This is like - this 253 00:22:50,540 --> 00:22:54,900 dialog here that you get in Thunderbird that ask if should I should a load remote 254 00:22:54,900 --> 00:22:59,580 images. Yes or no. This is basically everything that is keeping you from losing 255 00:22:59,580 --> 00:23:06,400 your your PGP or S/MIME ciphertext - S/MIME we're talking about S/MIME here. Now what we 256 00:23:06,400 --> 00:23:11,650 did next was we were asking ourselves, OK: It works with remote images. We understand 257 00:23:11,650 --> 00:23:16,200 this ,but what other back channels do we have? Back channel is something where 258 00:23:16,200 --> 00:23:20,690 your email client is communicating over the network. That's. So it's not 259 00:23:20,690 --> 00:23:26,460 necessarily exfiltrating but it's just like how can we convince a client to make 260 00:23:26,460 --> 00:23:33,150 a connection to somewhere else. Now I colored in red all the e-mail clients that 261 00:23:33,150 --> 00:23:37,940 require user interaction - that always require user interaction before it 262 00:23:37,940 --> 00:23:44,600 opens up a network connection somewhere. In orange we say that there's no user 263 00:23:44,600 --> 00:23:49,840 interaction. So these are the clients that allow for example loading remote images by 264 00:23:49,840 --> 00:23:54,470 default. OK. There's mail app for example there's gmail for example. They will not 265 00:23:54,470 --> 00:24:00,470 ask you they will just load it, OK? And but what we think is worse and therefore 266 00:24:00,470 --> 00:24:06,000 we colored it red are the clients that say we won't load remote images or any other 267 00:24:06,000 --> 00:24:11,650 way of communicating over the network. But then they will because we want bypasses. 268 00:24:11,650 --> 00:24:16,711 So because preventing loading remote images is basically a firewall and we 269 00:24:16,711 --> 00:24:23,210 bypass this local firewall and found several ways of extracting it. And there's 270 00:24:23,210 --> 00:24:27,549 even four or five of them that even allow JavaScript execution in a mail 271 00:24:27,549 --> 00:24:32,990 client. I mean come on this is really weird. So basically 40 of 47 clients have 272 00:24:32,990 --> 00:24:37,150 back channels that require no user interaction at all. And now we went out 273 00:24:37,150 --> 00:24:42,750 and tried to think about how can we exfiltrate plain text over it. And this 274 00:24:42,750 --> 00:24:48,809 is the final table the final result table for S/MIME and it looks pretty 275 00:24:48,809 --> 00:24:54,260 grim, right? So the red ones means it's vulnerable. That means we could exfiltrate 276 00:24:54,260 --> 00:24:59,539 plain text successfully. The ones with a dash they don't support S/MIME and Claws 277 00:24:59,539 --> 00:25:04,049 and Mutt we just didn't find any remote connection there. 278 00:25:04,049 --> 00:25:08,460 Okay. Which is good. Which is good. Yeah. That's a round of applause. Right. 279 00:25:08,460 --> 00:25:12,660 *applause* 280 00:25:12,660 --> 00:25:17,500 So I didn't say what S in S/MIME means. It actually means super. So it's super 281 00:25:17,500 --> 00:25:23,270 MIME. I don't know. Is it Super MIME? And basically his kryptonite. You know the the 282 00:25:23,270 --> 00:25:28,710 super villan of Super MIME is HTML. Right. You could say this. So S/MIME is broken 283 00:25:28,710 --> 00:25:34,070 by HTML and it's a very annoying kryptonite because it jumps you 284 00:25:34,070 --> 00:25:41,560 know like it's ugly colors. Now this is my Thunderbird that I have on my Mac at home. 285 00:25:41,560 --> 00:25:46,090 So this is like something that I recorded two days ago or so. And here I want to try 286 00:25:46,090 --> 00:25:52,940 to show you a way of exfiltrading the data without using HTML. So HTML here is 287 00:25:52,940 --> 00:25:59,030 disabled. This is the message that we want to break. And here we see the same message 288 00:25:59,030 --> 00:26:03,770 where we just changed, using gadgeting, we just changed the URL. 289 00:26:03,770 --> 00:26:10,210 So in Thunderbird when you disable HTML it will still highlight the links and when 290 00:26:10,210 --> 00:26:17,360 you click on it you're gonna exfiltrate plain text, right. So we require a little 291 00:26:17,360 --> 00:26:23,720 bit of user interaction but we can basically change a S/MIME ciphertext in a 292 00:26:23,720 --> 00:26:28,230 way that it will contain links and when you click a single link you will lose your 293 00:26:28,230 --> 00:26:34,000 your plain text. It's just a single click on it and the thing here is - I mean this 294 00:26:34,000 --> 00:26:38,401 is not a zero day in e-mail client, right? You just can't do anything about it. 295 00:26:38,401 --> 00:26:45,919 That's the problem. Okay. So people said okay so efail - just disable HTML and then 296 00:26:45,919 --> 00:26:51,600 you'll be fine. But the problem here is basically efail should work with any 297 00:26:51,600 --> 00:26:56,789 format that supports external connections. So as soon as you have a file format for 298 00:26:56,789 --> 00:27:01,740 example that supports external connections like PDF here, right? This is a PDF. When 299 00:27:01,740 --> 00:27:05,870 you click on it it will warn you and will say "Do you really want to make a 300 00:27:05,870 --> 00:27:12,170 connection to this domain?" And if you click "yes" you will do a connection there, 301 00:27:12,170 --> 00:27:18,281 right? And when you look at the how the URL is encoded in the PDF when you 302 00:27:18,281 --> 00:27:23,090 open the PDF in an hex editor you see it's just a string just like HTML, 303 00:27:23,090 --> 00:27:27,720 basically, right? So we could in theory use this as well. So you could change and 304 00:27:27,720 --> 00:27:32,409 S/MIME e-mail that it contains a PDF attachment and when you click the PDF 305 00:27:32,409 --> 00:27:37,030 attachment it will exfiltrate. With no user interaction, it works with with 306 00:27:37,030 --> 00:27:42,700 Microsoft Word for example. So that's a doc file and doc files allow external 307 00:27:42,700 --> 00:27:50,850 images that will load. It has no user interaction at all, so you just open it and 308 00:27:50,850 --> 00:27:55,059 the request will happen and the only problem that we're having here is it's not 309 00:27:55,059 --> 00:27:59,809 an ASCII URL, it's a Unicode URL. So I'm not sure whether this works with 310 00:27:59,809 --> 00:28:05,620 exfiltration but hey no user interaction, right? And. Now you could say "Okay PDF, 311 00:28:05,620 --> 00:28:10,221 Microsoft Word. That's very bad." - The same works in in LibreOffice and it's not a 312 00:28:10,221 --> 00:28:19,510 bug in the viewers, right? It's a basic feature that has been in these standards 313 00:28:19,510 --> 00:28:23,150 forever, right? So it's a thing that will be supported. It's not a zero day 314 00:28:23,150 --> 00:28:28,350 vulnerability in these viewers. It's just the file format support it, so you can 315 00:28:28,350 --> 00:28:34,000 abuse it. If you have some time: here's a challenge for you. If someone is able to 316 00:28:34,000 --> 00:28:42,780 make a successful demo for exfiltrating an S/MIME e-mail using a PDF or a doc file for 317 00:28:42,780 --> 00:28:49,010 example you will get a crate of Club Mate and some efail swag, if you want to? 318 00:28:49,010 --> 00:28:56,150 OK. So what happened after we disclosed it. Obviously we disclosed it to all the 319 00:28:56,150 --> 00:29:00,780 manufacturers and so on. And there's an S/MIME draft of a new RFC. So there's a 320 00:29:00,780 --> 00:29:05,299 working group and they already massaged the countermeasures into the 321 00:29:05,299 --> 00:29:11,110 current RFC draft. So for example to counter the CBC gadget attack they say: use 322 00:29:11,110 --> 00:29:19,895 a GCM which is not right now in the in the current RFC but in a draft it's already in. 323 00:29:19,895 --> 00:29:22,140 And so they're referencing the paper and they're saying: 324 00:29:22,140 --> 00:29:26,700 "OK you need to do this and do this as quickly as possible." And the second Efail 325 00:29:26,700 --> 00:29:32,820 attack which I'll talk about very soon is also mitigated in this in this RFC draft. 326 00:29:32,820 --> 00:29:39,030 OK. So S/MIME was pretty much broken. And you can just try to convince your e-mail 327 00:29:39,030 --> 00:29:45,790 client not to do any external connections. OK. That's all you have. Which at least, 328 00:29:45,790 --> 00:29:51,720 I mean, for cryptographer this means broken, OK? When you have to rely 329 00:29:51,720 --> 00:29:56,429 on the viewer not making any connections, the cryptography is broken. So what are 330 00:29:56,429 --> 00:30:02,310 the changes to OpenPGP because there are substantial differences to to OpenPGP. 331 00:30:02,310 --> 00:30:08,570 So first of all PGP uses a variation of the CFB-mode. It's not CBC-mode but CFB-mode. 332 00:30:08,570 --> 00:30:15,240 And they have pretty similar, they are very similar. So I won't show it here, 333 00:30:15,240 --> 00:30:19,860 if you are looking for the details, please look at the paper, but it's very similar. 334 00:30:19,860 --> 00:30:25,110 We can also flip bits and we also have these chunk bits in the middle and so on. 335 00:30:25,110 --> 00:30:29,590 What really caused a lot of headaches is the plain text compression. So that means 336 00:30:29,590 --> 00:30:37,580 in OpenPGP you don't encrypt directly the plain text but you deflate it 337 00:30:37,580 --> 00:30:42,010 before you encrypt it and that makes it very hard to guess plain text bytes, because 338 00:30:42,010 --> 00:30:47,340 for our attack to work we need to guess plain text bytes and when we know plain text 339 00:30:47,340 --> 00:30:52,990 certain parts of the plain text but it's deflated we have a problem. Okay? And what 340 00:30:52,990 --> 00:30:57,520 is also the most important thing is that OpenPGP defines a modification 341 00:30:57,520 --> 00:31:02,340 detection code, which is basically this is the message here. And the modification 342 00:31:02,340 --> 00:31:07,900 detection code is a hash of the message appended at the plain text and 343 00:31:07,900 --> 00:31:17,919 then encrypted. Okay? Which should detect plain text modifications. Now 344 00:31:17,919 --> 00:31:25,190 how does the OpenPGP standard say how to deal with broken MDCs when an MDC is not 345 00:31:25,190 --> 00:31:29,320 valid. Well, they say an implementation must treat an MDC failure as a security 346 00:31:29,320 --> 00:31:34,470 problem, but they don't say what is a security problem. What do you need to do 347 00:31:34,470 --> 00:31:39,750 then. And the implementation may allow the user access to the erroneous data. So the 348 00:31:39,750 --> 00:31:44,049 modified data may be passed on to the e-mail clients. 349 00:31:44,049 --> 00:31:49,840 And basically we tried to do this, right? But before we go there we looked at how 350 00:31:49,840 --> 00:31:53,730 many keys on the public key servers support MDCs at all. 351 00:31:53,730 --> 00:32:01,010 So MDC is a feature that came to OpenPGP in the early 2000s and before that it 352 00:32:01,010 --> 00:32:05,390 wasn't possible to use it. And so therefore to make this to make the change 353 00:32:05,390 --> 00:32:11,730 from software that doesn't use MDC versus software that that does use MDC they 354 00:32:11,730 --> 00:32:17,580 encoded in the key whether you support MDC or not. And here you see those keys that 355 00:32:17,580 --> 00:32:22,000 were generated in 2000 they don't support MDCs and the green ones - they support 356 00:32:22,000 --> 00:32:30,710 it. But, the problem is, when you accumulate all the valid keys in PGP that don't 357 00:32:30,710 --> 00:32:37,190 support MDCs we still see that at the key servers right now in 2017 we have 358 00:32:37,190 --> 00:32:42,289 something like one point seven million of the keys that don't support MDC. So when I 359 00:32:42,289 --> 00:32:48,560 sent an email to one of these people my implementation will not use an MDC, or 360 00:32:48,560 --> 00:32:55,330 right? They - yeah I'll come to this later. So we thought about okay how 361 00:32:55,330 --> 00:33:00,070 can we make a structured analysis how the MDC is treated with. The OpenPGP standard 362 00:33:00,070 --> 00:33:05,419 is not clear what to do with it. And so we have three test cases. First of all, we 363 00:33:05,419 --> 00:33:10,909 try to strip the MDC. So we just use this encrypted packet here and strip off at the 364 00:33:10,909 --> 00:33:17,039 end. We just say OK it's incorrect, right? So we make our modification in the 365 00:33:17,039 --> 00:33:24,080 plain text and see whether they will detect this error or we could also do this 366 00:33:24,080 --> 00:33:29,230 downgrade from the packet type that supports MDC to the old packet type that 367 00:33:29,230 --> 00:33:34,840 does not support MDC, right? And when we check this, especially with the most widely 368 00:33:34,840 --> 00:33:40,260 used clients we saw that Thunderbird and Enigmail and Apple Mail and GPG tools they 369 00:33:40,260 --> 00:33:46,070 basically ignored the MDC and that was the reason why we didn't see the MDC as very 370 00:33:46,070 --> 00:33:51,670 important because in our test systems it wasn't just treated, OK? 371 00:33:51,670 --> 00:33:57,700 Now what are the Efail related changes to OpenPGP. And we're talking about the 372 00:33:57,700 --> 00:34:02,610 changes that were done after we disclosed this to them. 373 00:34:02,610 --> 00:34:05,640 First of all they made something that is very important. 374 00:34:05,640 --> 00:34:11,090 They say that the packet type and PGP that does not support MDC is now obsolete. So 375 00:34:11,090 --> 00:34:16,220 you must not use this packet type anymore. You must ignore it. Which also means that 376 00:34:16,220 --> 00:34:21,520 when you have used non MDC messages in your mailbox you will not be able to open 377 00:34:21,520 --> 00:34:28,340 them anymore, OK? Yeah. That's a problem. Then they also said: "OK, what 378 00:34:28,340 --> 00:34:33,860 is supposed to happen when the MDC was wrong?" And this is the text that we 379 00:34:33,860 --> 00:34:38,360 have already seen where we said "the implementation may allow the user access 380 00:34:38,360 --> 00:34:43,240 to the erroneous data" and they changed this in the current draft to "the 381 00:34:43,240 --> 00:34:48,280 implementation should not allow the user to process the erroneous data." Right? They 382 00:34:48,280 --> 00:34:53,190 must still warn the user. And so on and so on. But it should not allow the user, which 383 00:34:53,190 --> 00:35:02,410 is good. That's a good change. So this was the - this MDC check is a bit troublesome 384 00:35:02,410 --> 00:35:08,450 because it's right at the end of the plain text, so you can only check the MDC 385 00:35:08,450 --> 00:35:13,250 when you have fully decrypted the message which means when you have a large e-mail 386 00:35:13,250 --> 00:35:18,510 or a large back-up or so you have to fully decrypt it and afterwards only you can tell 387 00:35:18,510 --> 00:35:24,430 whether it was valid or not. And the solution of GnuPG is that it will just 388 00:35:24,430 --> 00:35:30,619 stream - while it decrypts it will stream the data to to the e-mail client and 389 00:35:30,619 --> 00:35:34,700 afterwards tell it whether it's supposed to use it or not, OK? So here's your 390 00:35:34,700 --> 00:35:39,891 email, here's your e-mail, here's your - Oh no! You must not use it, please forget it, right? 391 00:35:39,891 --> 00:35:44,980 Which is not fine. This is not a safe way of doing it. So the current OpenPGP draft, 392 00:35:44,980 --> 00:35:48,690 before Efail, before we did the disclosure already supported something 393 00:35:48,690 --> 00:35:53,520 that they called chunking. So they not only have an MDC some kind of a MAC at the 394 00:35:53,520 --> 00:35:57,800 end of the plain text, but they chunk it into more chunks and each of these 395 00:35:57,800 --> 00:36:04,670 has a MAC - a real MAC - which is much better because, right? You can authenticate chunks 396 00:36:04,670 --> 00:36:13,660 and cache it before you give it to the app. The problem is that the standard says 397 00:36:13,660 --> 00:36:20,920 that 120MB is like a good chunk size which is far too big, right? Far too big. 398 00:36:20,920 --> 00:36:26,370 And when we look at the Efail related changes to GnuPG. So for example MDCs 399 00:36:26,370 --> 00:36:31,541 where they used to be warnings. So when GnuPG was detecting that an MDC is not 400 00:36:31,541 --> 00:36:37,589 there or it's wrong, they would just warn it but it would still print it out. GnuPG 401 00:36:37,589 --> 00:36:45,260 now, like, fails it makes a hard failure now and GnuPG now always uses the MDC 402 00:36:45,260 --> 00:36:50,811 independently if the key denotes that the receiver can use it or not. Which 403 00:36:50,811 --> 00:36:54,650 is also very good but it is a breaking change, rightß So when you have people that 404 00:36:54,650 --> 00:36:58,290 send you PGP e-mails and you can't decrypt them anymore you have to tell them that 405 00:36:58,290 --> 00:37:05,630 they need to update GnuPG. They also say that the default chunk size 406 00:37:05,630 --> 00:37:11,599 is 120 megabyte which means they still stream unauthenticated plaintext so they 407 00:37:11,599 --> 00:37:17,960 missed this opportunity to make this go away, which is a pity. 408 00:37:17,960 --> 00:37:24,380 Okay. What is not answered neither by S/MIME nor by PGP: How to deal with past 409 00:37:24,380 --> 00:37:28,150 e-mails? So, basically all the emails that you're sending in S/MIME encrypted right 410 00:37:28,150 --> 00:37:34,690 now are insecure and the old ones that don't use MDC in PGP they are also not 411 00:37:34,690 --> 00:37:39,480 secure and nobody talks about what's supposed to happen with them, right? 412 00:37:39,480 --> 00:37:43,920 Okay, that was the interesting attack. That 413 00:37:43,920 --> 00:37:46,790 was the one that was really cryptographically involving, 414 00:37:46,790 --> 00:37:51,130 that required changes to the standards and so on. Now let's look at something that's 415 00:37:51,130 --> 00:37:56,790 a bit more silly. Okay, so we have Alice writes an e-mail to Bob, we encrypt it and 416 00:37:56,790 --> 00:38:02,730 send it off to Bob. Now here we have the original e-mail and now Eve composes an 417 00:38:02,730 --> 00:38:08,680 attack e-mail. And it somehow gained access to the PGP ciphertext, it also works for 418 00:38:08,680 --> 00:38:13,140 S/MIME, right, it's independent. It's a vulnerability in the in the mail clients. 419 00:38:13,140 --> 00:38:18,349 And now we don't change the ciphertext we just surround it with other MIME parts 420 00:38:18,349 --> 00:38:24,310 that are of type HTML and that exfiltrated the same as we did before only that we 421 00:38:24,310 --> 00:38:28,910 don't need to change the ciphertext at all, right? 422 00:38:28,910 --> 00:38:34,109 So basically when this is decrypted it will be replaced with a plain text in 423 00:38:34,109 --> 00:38:38,950 place and then it will be merged into one document. And now I have to tell you 424 00:38:38,950 --> 00:38:44,840 something that many people don't seem to know. All mail clients, except mutt, they 425 00:38:44,840 --> 00:38:51,800 use HTML to view emails. So even when you disable HTML it basically means that they 426 00:38:51,800 --> 00:38:57,531 will use incoming HTML e-mails, parse them, transform them into something that 427 00:38:57,531 --> 00:39:04,450 looks like ASCII and display this in HTML. Okay. So, right? There is no such thing as 428 00:39:04,450 --> 00:39:10,440 ASCII e-mails with most of the clients. So but here now you have one HTML document 429 00:39:10,440 --> 00:39:15,990 which basically means the same, it will exfiltrate and very easy. Okay? So let's 430 00:39:15,990 --> 00:39:22,400 look here and on this video here we have we create one ciphertext we encrypt it. We 431 00:39:22,400 --> 00:39:29,230 use Apple Mail because this was one of the two vulnerable clients and we just open this 432 00:39:29,230 --> 00:39:36,630 email in order to view the PGP ciphertext, right? We look at the raw code of the 433 00:39:36,630 --> 00:39:45,360 ciphertext, raw source and we scroll down and there we see there's the PGP message, 434 00:39:45,360 --> 00:39:52,530 OK? Now in the next minute Eve somehow gained access to this ciphertext and it 435 00:39:52,530 --> 00:40:01,310 will compose a attacker email which is hidden in a python program that we just 436 00:40:01,310 --> 00:40:06,140 use to generate an e-mail, so this happened now in the background, you will 437 00:40:06,140 --> 00:40:13,910 see an e-mail is incoming. Here we just open the access log for this and when 438 00:40:13,910 --> 00:40:20,690 we click on it, right at this time, it will be exfiltrated. Okay. So very easy attack, 439 00:40:20,690 --> 00:40:24,950 anyone can do this, you don't need to know anything about cryptography you only need 440 00:40:24,950 --> 00:40:28,970 to understand a little bit of HTML and a little bit of MIME and you can execute 441 00:40:28,970 --> 00:40:37,119 this. You know what's worse than this? How about we just exfiltrate many e-mails with 442 00:40:37,119 --> 00:40:42,050 a single attack e-mail because we could basically use - here we open an image, 443 00:40:42,050 --> 00:40:46,700 here's the ciphertext. Here would close it. Then we open another image. Here's the 444 00:40:46,700 --> 00:40:51,680 second ciphertext. Then we close it. Then we open a third one and so on and so on. 445 00:40:51,680 --> 00:40:56,910 And what you see here, on the left hand side you see there's 100 ciphertext packed 446 00:40:56,910 --> 00:41:02,630 into one e-mail that is sent to this client. I blurred this because I used 100 447 00:41:02,630 --> 00:41:08,800 GPG e-mails that I sent, right? I didn't want to show them to you. Now this takes 448 00:41:08,800 --> 00:41:13,050 some time. Now it's like decrypting, decrypting, decrypting, decrypting. And when 449 00:41:13,050 --> 00:41:17,580 you look at the terminal on the left side you see 100 e-mails getting exfiltated, 450 00:41:17,580 --> 00:41:23,599 right? Automatically simply by opening a single email. Okay this is horrifying. 451 00:41:23,599 --> 00:41:30,700 *Applause* 452 00:41:30,700 --> 00:41:34,839 And when I say horrifying I'm really literally mean: this is horrifying. So we 453 00:41:34,839 --> 00:41:40,099 were like afraid OK when we disclose this then people will start attacking this 454 00:41:40,099 --> 00:41:48,410 within the hour or so, OK? And so we disclosed this in early 2018. End of 2017, 455 00:41:48,410 --> 00:41:57,010 early 2018. And in May 2018 we had already shifted the disclosure date twice and in 456 00:41:57,010 --> 00:42:01,680 May we said OK we won't shift this anymore. And so therefore we said OK we go 457 00:42:01,680 --> 00:42:06,309 online but we want to make a preannouncement. We want to 458 00:42:06,309 --> 00:42:11,690 warn the people that if you use PGP or S/MIME for very sensitive 459 00:42:11,690 --> 00:42:17,000 communication you should disable it in your e-mail client for now. These are the 460 00:42:17,000 --> 00:42:22,720 original tweets that we sent and we said: OK, In a day, OK, when you have done this 461 00:42:22,720 --> 00:42:27,050 then we will disclose everything, OK? We will go online with the paper and 462 00:42:27,050 --> 00:42:33,020 everything. And now I mean people started talking about it and then the GnuPG people 463 00:42:33,020 --> 00:42:37,950 started tweeting and they basically broke the embargo. So they told OK the attack is 464 00:42:37,950 --> 00:42:41,310 working like this. First you do this and then you do that and then you do that and 465 00:42:41,310 --> 00:42:45,160 they were blabbing and so on and then they sent it, which is annoying, but then they 466 00:42:45,160 --> 00:42:49,780 sent this. So they said know that new GnuPG team was not contacted by them in 467 00:42:49,780 --> 00:42:55,700 advance. And this, this really, OK? Then it got really hot. Okay. 468 00:42:55,700 --> 00:43:00,380 This is not true. I will show you later, but I mean this tipped off almost anyone 469 00:43:00,380 --> 00:43:06,160 in the INFOSEC community. And we got hate e-mails and yeah people were really mad 470 00:43:06,160 --> 00:43:10,200 with them, I posted "We did contact them." and this is like the, these are the 471 00:43:10,200 --> 00:43:13,820 original dates when I talked with Werner Koch which is the main developer of of 472 00:43:13,820 --> 00:43:18,150 GnuPG. But it was too late. I mean they they recognized that they said: "Oh yeah, oh 473 00:43:18,150 --> 00:43:25,380 I forgot!" Right? That they sent this paper here. That writes EFAIL with our names and 474 00:43:25,380 --> 00:43:31,430 a date and an embargo and so on and so on. And they said they forgot it, OK? But I 475 00:43:31,430 --> 00:43:37,180 mean we lost at this point, OK? People were hating us. I was called a murderer. 476 00:43:37,180 --> 00:43:41,290 And and so on and so on and so it was really, really weird. If you're interested 477 00:43:41,290 --> 00:43:45,150 of how things worked, right, this is an independent summary of the disclosure 478 00:43:45,150 --> 00:43:50,790 timeline from Thomas Ptacek which is not involved with us at all we have never met 479 00:43:50,790 --> 00:43:55,190 him, but who was so kind to just compile this just from public information that are 480 00:43:55,190 --> 00:44:01,590 really reliable. So and then something happened that 481 00:44:01,590 --> 00:44:07,320 we what we could foresee. People were finding - like there were some patches - 482 00:44:07,320 --> 00:44:12,130 and I told you already that we saw that these patches are not sufficient. 483 00:44:12,130 --> 00:44:18,630 And two days later people came up with new style of attacks, new EFAIL attacks and 484 00:44:18,630 --> 00:44:23,040 this was Hanno who found something. So he said I found a trivial bypass EFAIL is 485 00:44:23,040 --> 00:44:27,660 still exploitable with the latest Enigmail and Thunderbird - that is three days after 486 00:44:27,660 --> 00:44:32,030 we did the disclosure and he responsibly disclosed this and so on and so on. So 487 00:44:32,030 --> 00:44:37,460 everything is fine. Micah Lee, from The Intercept, also developed a proof of 488 00:44:37,460 --> 00:44:43,080 concept exploit that works against Apple Mail and GPG tools also 2 or 3 days later. 489 00:44:43,080 --> 00:44:48,030 So we were right, right? So people were finding ways to circumvent the fixes that 490 00:44:48,030 --> 00:44:54,780 were in there. But still I mean, OK, media was blowing up, OK? And we didn't actually 491 00:44:54,780 --> 00:45:01,849 understand what was really going on there. But you have to know I mean PGP is like, 492 00:45:01,849 --> 00:45:07,210 one of the main users of PHP, eh of PGP is journalists, right. 493 00:45:07,210 --> 00:45:11,130 So and they basically, I mean you show it to them look that's the attack and they 494 00:45:11,130 --> 00:45:16,690 will like what? That's how easy it is? And that's what you see in the press I guess. 495 00:45:16,690 --> 00:45:23,050 So what are the lessons learned from the disclosure. So first of all: people kept 496 00:45:23,050 --> 00:45:27,119 complaining, I mean people kept complaining to us that we didn't stick to 497 00:45:27,119 --> 00:45:32,310 the 90 day disclosure deadline. So we had more than 200 days disclosure and 498 00:45:32,310 --> 00:45:36,500 we postponed it and so on and so on. And in the aftermath it didn't make sense 499 00:45:36,500 --> 00:45:40,680 because we were postponing and postponing it and there were still no reliable fixes. 500 00:45:40,680 --> 00:45:43,910 So we should have stuck to the 90 day disclosure deadline because after we 501 00:45:43,910 --> 00:45:48,050 disclosed it they were in a rush. They released patches and stuff like, you know? 502 00:45:48,050 --> 00:45:54,190 So it was, yeah. Be careful with disclosure preannouncements. The problem 503 00:45:54,190 --> 00:46:00,861 here is people will speculate about the details. You know, because when you say: "OK 504 00:46:00,861 --> 00:46:04,650 we'll disclose something tomorrow but we're not going to speak today" - then 505 00:46:04,650 --> 00:46:08,839 journalists will speak to some random people, right? That they just get their 506 00:46:08,839 --> 00:46:14,390 hands on and they will just try to guess what it could be. And this means they will 507 00:46:14,390 --> 00:46:19,700 underrate the risk or they will overrate the risk. Underrate the risk is just 508 00:46:19,700 --> 00:46:23,540 disable external images, loading external images, then you're fine. That is 509 00:46:23,540 --> 00:46:30,240 underrating and overrating is like: "OK, PGP is broken, forever", right? Which is not 510 00:46:30,240 --> 00:46:34,510 the case. And they will spread this false information and you still see this out 511 00:46:34,510 --> 00:46:40,630 there, right? It's documented. People have issued like papers and so on and so on 512 00:46:40,630 --> 00:46:45,320 with wrong information, provably wrong information. Which is bad and so these 513 00:46:45,320 --> 00:46:48,480 disclosure preannouncements are bad because you're not in control of the 514 00:46:48,480 --> 00:46:53,040 communication anymore. That's very bad. And controlling information flow really is 515 00:46:53,040 --> 00:46:57,200 key after you do the disclosure because otherwise you get the wrong story out and 516 00:46:57,200 --> 00:47:05,810 this this doesn't help at all. Okay. Let's look at the last attack, and we call this 517 00:47:05,810 --> 00:47:10,300 reply to attacker. And I have to give credit to the people of 518 00:47:10,300 --> 00:47:16,730 Cure53, which also found this bug or a similar very similar version of this bug 519 00:47:16,730 --> 00:47:20,859 as well and disclosed it. But they were first to disclose it so credit goes to 520 00:47:20,859 --> 00:47:27,270 them, OK? Here, the attacker scenario is I get an e-mail from some person which 521 00:47:27,270 --> 00:47:32,280 makes sense. It's a benign e-mail. Okay. It doesn't look bad at all. And a person 522 00:47:32,280 --> 00:47:37,051 wants to trick me to answer this e-mail. So this is the e-mail that I get. There's 523 00:47:37,051 --> 00:47:42,940 some footer here and stuff like that. And now we look in the video, it's an old 524 00:47:42,940 --> 00:47:51,000 version of Mail that we use here. Right. This is the e-mail. We just - and I answer 525 00:47:51,000 --> 00:47:54,640 it, right? Because people were asking me for an appointment they want to 526 00:47:54,640 --> 00:47:58,730 meet me and I was like yeah sure after my talk let's just meet. And this is the 527 00:47:58,730 --> 00:48:05,000 attacker e-mail that the attackers opened and when you look closely down here you'll 528 00:48:05,000 --> 00:48:10,790 see secret stuff here that shouldn't be in there and that I didn't send actually. 529 00:48:10,790 --> 00:48:17,190 Let's look at the plain text of this e-mail and the source code of this e-mail. 530 00:48:17,190 --> 00:48:23,690 And when you scroll down you see it's a mix of just a normal, just a normal 531 00:48:23,690 --> 00:48:28,330 e-mail, benign e-mail. And down here you find a ciphertext it can be S/MIME it can 532 00:48:28,330 --> 00:48:35,270 be PGP. It doesn't really matter. And what's happening now is: 533 00:48:35,270 --> 00:48:39,700 I get this e-mail, this here will be decrypted from my mail client and I don't 534 00:48:39,700 --> 00:48:44,260 see it because I won't scroll down. I'm a lazy person I'm a top poster. Right, now 535 00:48:44,260 --> 00:48:50,180 you can go boo and so on, OK. But still I mean top posting is considered evil here. 536 00:48:50,180 --> 00:48:55,250 Because I basically - the attacker was sending me an e-mail where ciphertext was 537 00:48:55,250 --> 00:48:59,940 hidden in there that my e-mail client was decrypting and I was replying to this 538 00:48:59,940 --> 00:49:04,200 e-mail sending the attacker the actual plain text that I just decrypted, without 539 00:49:04,200 --> 00:49:10,530 knowing it. Okay that's silly. Okay. Come on. That's really silly. Okay. What are 540 00:49:10,530 --> 00:49:16,099 you supposed to do now. What are the things that you should do. And the 541 00:49:16,099 --> 00:49:20,829 important question here is you should ask yourself are you targeted by motivated 542 00:49:20,829 --> 00:49:23,310 attackers? And a motivated attacker is not 543 00:49:23,310 --> 00:49:29,230 necessarily the NSA or so, right? It can be just, I don't know, Cybercrime people or 544 00:49:29,230 --> 00:49:35,359 so. I mean we we basically came up with these attacks with 8 people abd the better 545 00:49:35,359 --> 00:49:40,270 part of a year. Which is not you know, which is a lot of research actually but 546 00:49:40,270 --> 00:49:44,521 it's not like comparable to a nation state. Right. So if you're targeted by a 547 00:49:44,521 --> 00:49:50,420 motivated attacker and if you say yeah you are probably targeted by motivated 548 00:49:50,420 --> 00:49:55,150 attackers then avoid e-mail in total. E-mail is not made for secure 549 00:49:55,150 --> 00:50:01,990 communication. Okay. If you can't avoid it and there's people who can't avoid using 550 00:50:01,990 --> 00:50:06,790 e-mail they can't just use signal or any other chat client, then definitely use 551 00:50:06,790 --> 00:50:15,000 OpenPGP and encrypt and decrypt outside of the mail client. If you are probably not 552 00:50:15,000 --> 00:50:21,960 targeted by motivated attackers, which is most of you and I presume I would count to 553 00:50:21,960 --> 00:50:27,510 the same people here, definitely prefer OpenPGP over S/mime because S/mime remains 554 00:50:27,510 --> 00:50:32,370 broken. Right, there is a standard coming up which fixes most of the stuff. Disable 555 00:50:32,370 --> 00:50:39,210 HTML for encrypted emails and this is like not that easy. Note that most email 556 00:50:39,210 --> 00:50:45,440 clients use HTML by default and it might be okay if you fix it, the people that I 557 00:50:45,440 --> 00:50:51,020 hear in the audience. But think of all the people who are not here in this audience, 558 00:50:51,020 --> 00:50:56,260 who are not technically versed and so on and so on and they will not disable HTML, 559 00:50:56,260 --> 00:51:00,800 right. So be careful with attachments which is also very difficult, how can you 560 00:51:00,800 --> 00:51:05,359 be careful with attachments. Right. This is not very good. And don't top post, 561 00:51:05,359 --> 00:51:12,589 don't cite text in a reply. Okay. That was my talk. If you want to meet us afterwards 562 00:51:12,589 --> 00:51:16,670 we're gonna go to the Chaos West. There's a huge and lighted palm and we'll be there 563 00:51:16,670 --> 00:51:23,020 if you have questions you can ask us there. Thank you very much. 564 00:51:23,020 --> 00:51:33,190 *applause* 565 00:51:33,190 --> 00:51:37,780 Herald: Thanks a lot Sebastian, for this interesting talk. We still have some time 566 00:51:37,780 --> 00:51:41,960 for questions, so if you would like to ask some questions to Sebastian then please 567 00:51:41,960 --> 00:51:47,170 queue up behind the microphones, and please try to be concise with your 568 00:51:47,170 --> 00:51:51,319 question, and please get close to the microphone, because the mixing Angel in 569 00:51:51,319 --> 00:51:56,180 the back is able to make it quieter, but hardly much louder, if your distance is 570 00:51:56,180 --> 00:51:59,050 not right. So let's start with microphone number 2. 571 00:51:59,050 --> 00:52:05,950 Microphone 2: Test, test. Hello. I'm actually tested the HTML exfiltrate you 572 00:52:05,950 --> 00:52:18,589 described. But I found out, in Thunderbird, the HTML parsing of 573 00:52:18,589 --> 00:52:20,950 Thunderbird was actually helping against the attack, because the word tags was just 574 00:52:20,950 --> 00:52:25,910 disabled any possibility to exfiltrate the message, because there were some div tag, 575 00:52:25,910 --> 00:52:31,760 which is closing your image tag at every point in time 576 00:52:31,760 --> 00:52:37,140 Sebastian: Yeah, so, this is one of the fixes, that they did. I mean it doesn't 577 00:52:37,140 --> 00:52:40,990 help with the cryptography, but it makes the exeltration a bit more difficult. If 578 00:52:40,990 --> 00:52:45,890 you want to do the testing, try the versions from before May this year. 579 00:52:45,890 --> 00:52:48,942 Microphone 2: I did, I did with the old versions. 580 00:52:48,942 --> 00:52:51,680 Sebastian: We can talk afterwards if you want, and I will show it to you. 581 00:52:51,680 --> 00:52:56,690 Herald: We are streaming all the talks on the Internet and we have people on the 582 00:52:56,690 --> 00:53:00,210 internet that would like to ask a question, so please a question from the 583 00:53:00,210 --> 00:53:02,630 internet. Signal Angel: Yeah, so there were actually 584 00:53:02,630 --> 00:53:03,748 many questions in the direction of problems with MIME standards. So, like, 585 00:53:03,748 --> 00:53:05,040 what they were asking was basically "Woudn't the exploitation be prevented, if 586 00:53:05,040 --> 00:53:21,270 the email clients would handle the standart correctly?" 587 00:53:21,270 --> 00:53:26,790 Sebastian: Mhm, okay. So, I am not sure whether they meant the MIME standards or 588 00:53:26,790 --> 00:53:31,710 the S/MIME standards. So basically, the MIME standards are that one to blame for 589 00:53:31,710 --> 00:53:37,150 the direct exoltration attacks, were you have multiple MIME-parts that are mixed 590 00:53:37,150 --> 00:53:42,710 together, and the MIME standards don't state explicitly how to do this. So they 591 00:53:42,710 --> 00:53:48,339 don't have any rules of how to handle it, and basically I think, as a rule of thumb, 592 00:53:48,339 --> 00:53:53,500 when you try to be concise and complete with implementing the MIME standard you 593 00:53:53,500 --> 00:53:58,680 were vulnerable, and if you were just lazy and just for example decrypted the first 594 00:53:58,680 --> 00:54:04,110 MIME-part or so you were not vulnerable. So, leaving out much of the stuff made you 595 00:54:04,110 --> 00:54:08,810 more secure, which is weird. Herald: Thank you for the answer. We have 596 00:54:08,810 --> 00:54:12,680 another question in this hall, on microphone number 6, and please remember 597 00:54:12,680 --> 00:54:14,401 to be concise and get close to the microphone. 598 00:54:14,401 --> 00:54:16,740 Microphone 6: What do you see *Audio feedback loop* 599 00:54:16,740 --> 00:54:19,750 Microphone 6: Sorry. Herald: Very good! We can always make it 600 00:54:19,750 --> 00:54:20,750 quieter. *Applause* 601 00:54:20,750 --> 00:54:22,270 Herald: *Laughing* 602 00:54:22,270 --> 00:54:25,970 Microphone 6: What do you see as a future 603 00:54:25,970 --> 00:54:31,430 replacement to PGP for email encryption? Sebastian: So actually, we brainstormed a 604 00:54:31,430 --> 00:54:37,579 little, because PGP lacks many of the modern properties, like forward secrecy 605 00:54:37,579 --> 00:54:43,100 and stuff like this, but it turns out that it's not very easy to do this. Especially 606 00:54:43,100 --> 00:54:50,079 not with - when you don't want to do changes to SMTP and IMAP. So, it's gonna 607 00:54:50,079 --> 00:54:57,069 be difficult. It's gonna be difficult to make it more secure than PGP, besides the 608 00:54:57,069 --> 00:55:04,930 critisism that I already brought in. So, E-Mail is not a very good protocol, or the 609 00:55:04,930 --> 00:55:09,069 protocols that are built in E-Mail are not a very good to build proper crypto on top 610 00:55:09,069 --> 00:55:12,650 of it. Herald: Thank you for this answer, so 611 00:55:12,650 --> 00:55:17,560 maybe we need build something entirely new from scratch. There is another question on 612 00:55:17,560 --> 00:55:20,130 Microphone number 2, if I see this correctly. 613 00:55:20,130 --> 00:55:26,460 Microphone 2: So, do I understand it correctly, it looks like there won't be a 614 00:55:26,460 --> 00:55:33,050 fix for that multi part attacks, like there is the normal plain text the 615 00:55:33,050 --> 00:55:36,650 attacker writes, and then there is a ciphertext, which my mail client decrypts; 616 00:55:36,650 --> 00:55:40,650 there won't be a fix for that? Sebastian: There is a fix, so the mail 617 00:55:40,650 --> 00:55:44,839 clients are fixed, so that's because that's a non-breaking fix, that's a good 618 00:55:44,839 --> 00:55:49,089 thing here. So you can't fix S/MIME, for example, because it would be a breaking 619 00:55:49,089 --> 00:55:55,020 fix, but you could fix the email clients, which was a lot of work, because MIME 620 00:55:55,020 --> 00:55:59,190 parsers are very complex, but they fixed it, so it's not supposed to work in 621 00:55:59,190 --> 00:56:03,470 current mail clients anymore. The direct exfiltration part. 622 00:56:03,470 --> 00:56:08,380 Herald: So we still have quite some time left and so I would like to have another 623 00:56:08,380 --> 00:56:11,320 question form the internet. Signal Angel: Yes, so one user asked 624 00:56:11,320 --> 00:56:14,440 "would you recommend a better path to integrate PGP into the E-Mail 625 00:56:14,440 --> 00:56:27,150 clients instead of using extensions?" Sebastian: Yea. I'm not a - I mean 626 00:56:27,150 --> 00:56:31,920 I already talked about this that not many people use PGP. And also not many people 627 00:56:31,920 --> 00:56:36,750 use S/MIME. I'm not sure, whether this will be 628 00:56:36,750 --> 00:56:45,140 increased, when OpenPGP spilled into most of the mail clients, because you could use 629 00:56:45,140 --> 00:56:50,750 S/MIME, you know. As soon as S/MIME is fixed it will be fine to use S/MIME, and 630 00:56:50,750 --> 00:56:54,661 it's already in all the clients in there, but not many people use it. 631 00:56:54,661 --> 00:56:59,900 So it would be nice, if we could have it, but I'm not sure whether it would have 632 00:56:59,900 --> 00:57:06,910 much of an effect on the amount of people who use it. Herald Angel: Thank you. And 633 00:57:06,910 --> 00:57:10,849 we have another question from Microphone number 7. 634 00:57:10,849 --> 00:57:16,819 Microphone 7: Yes, hello. So I work with journalists - here! here! here! 635 00:57:16,819 --> 00:57:20,040 Herald Angel: There, in the very back. Microphone 7: There, Hello. Hello. 636 00:57:20,040 --> 00:57:21,599 Sebastian: Hi. Oh, yeah hi. How's it going? 637 00:57:21,599 --> 00:57:27,340 Microphone 7: So I work with journalists, and May was very annoying, and I cannot 638 00:57:27,340 --> 00:57:32,369 stress enough how important it is to - the point you've made about communicating 639 00:57:32,369 --> 00:57:33,440 around disclosure. Sebastion: Yeah 640 00:57:33,440 --> 00:57:37,470 Microphone 7: We were scrambling. I work with about 200 journalists, who use PGP 641 00:57:37,470 --> 00:57:40,710 daily, and we were scrambling for any bit of information. 642 00:57:40,710 --> 00:57:43,119 Sebastian: Yeah. Microphone 7: What, what should we do? It 643 00:57:43,119 --> 00:57:44,390 was, it was madness. Sebastian: Yes. 644 00:57:44,390 --> 00:57:49,250 Microphone 7: But I actually have a question. The question is: Have you played 645 00:57:49,250 --> 00:57:55,500 with Mailpile? I've read the, I've read the paper. In the paper Mailpile, I think 646 00:57:55,500 --> 00:58:01,700 I remember, was mentioned, and I vaguely remember it was mentioned in a positive 647 00:58:01,700 --> 00:58:07,619 light, but I just want to make sure, if that's the right thing that I should get 648 00:58:07,619 --> 00:58:10,230 from this paper. Sebastian: I don't know it on the top of 649 00:58:10,230 --> 00:58:15,910 my head, but if you come afterwards to Chaos West we'll get out the paper and 650 00:58:15,910 --> 00:58:18,690 look at the tests, and then we can answer this question. Cool. 651 00:58:18,690 --> 00:58:22,060 Microphone 7: Thank you. Herald: Okay. We have another question on 652 00:58:22,060 --> 00:58:27,569 the microphone number 6. Microphone 6: So, I'd like to know if 653 00:58:27,569 --> 00:58:37,050 there's any difference in the attack surface, regarding OpenPGP, if plain, 654 00:58:37,050 --> 00:58:47,190 like, plain PGP is used or PGP/MIME. For example if you set your E-Mail client to 655 00:58:47,190 --> 00:58:58,170 disallow decryption of inline PGP. Sebastian: Yeah, that's a very good 656 00:58:58,170 --> 00:59:02,320 question. I mean the reply to attacker attack that I 657 00:59:02,320 --> 00:59:08,230 just showed at the last. The Q53 people came up with a version that worked with 658 00:59:08,230 --> 00:59:15,729 inline PGP, and we showed that it's also possible with PGP/MIME. So, I wouldn't say 659 00:59:15,729 --> 00:59:22,170 - I mean, most of the people use PGP/MIME. Inline PGP is not used anymore. The 660 00:59:22,170 --> 00:59:27,280 problem is, when you don't decrypt PGP, inline PGP, then you have a problem when 661 00:59:27,280 --> 00:59:32,520 people use PGP at an external application. They can't copy and paste the ciphertext 662 00:59:32,520 --> 00:59:37,170 in there anymore, which is also very annoying. And I also told you that it's, I 663 00:59:37,170 --> 00:59:40,910 think it's a very good idea to do this outside of the mail client, if you're in 664 00:59:40,910 --> 00:59:47,590 a, if you face motivated attackers. So, it's not that easy. it would be a breaking 665 00:59:47,590 --> 00:59:50,380 change that wouldn't, maybe not be too good. 666 00:59:50,380 --> 00:59:54,250 Microphone 6: Okay. Thanks. Sebastian: Okay. 667 00:59:54,250 --> 00:59:58,660 Herald: Thanks a lot for this answer. I think we are done with all the questions 668 00:59:58,660 --> 01:00:03,330 from the hall. If you like to continue the discussion with Sebastian Schinzel, you 669 01:00:03,330 --> 01:00:09,151 may move yourself to the assembly of Chaos West in the next hall in this direction. 670 01:00:09,151 --> 01:00:11,980 And now please give a big round of applause for Sebastian Schinzel and the 671 01:00:11,980 --> 01:00:14,880 awesome team behind. *Applause* 672 01:00:14,880 --> 01:00:18,815 *Outro plays* 673 01:00:18,815 --> 01:00:38,000 subtitles created by c3subtitles.de in the year 2020. Join, and help us!