0 00:00:00,000 --> 00:00:30,000 Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/639 Thanks! 1 00:00:13,410 --> 00:00:16,679 And the next talk is about 2 00:00:16,680 --> 00:00:17,790 the drone attack. 3 00:00:19,040 --> 00:00:21,119 It's secured, I said it will 4 00:00:21,120 --> 00:00:22,859 be fun, he said, and smash it with a 5 00:00:22,860 --> 00:00:23,860 computer camera. 6 00:00:24,900 --> 00:00:26,369 So my Ascension Sentience has been 7 00:00:26,370 --> 00:00:28,049 interested in I.T. 8 00:00:28,050 --> 00:00:29,879 security since a long time. 9 00:00:29,880 --> 00:00:31,979 His sir PHC at their 10 00:00:31,980 --> 00:00:32,980 prime minster. 11 00:00:33,900 --> 00:00:35,959 And you may recall his talks 12 00:00:35,960 --> 00:00:38,199 back at thirty one. 13 00:00:38,200 --> 00:00:40,259 Twenty eight or 14 00:00:40,260 --> 00:00:41,479 even twenty nine. 15 00:00:41,480 --> 00:00:42,480 C three. 16 00:00:43,440 --> 00:00:46,229 Today he will talk about the drone attack 17 00:00:46,230 --> 00:00:48,559 and how to attack 18 00:00:48,560 --> 00:00:50,699 s. By making use of a server 19 00:00:50,700 --> 00:00:53,029 that supports s us ldv to please 20 00:00:53,030 --> 00:00:54,809 Volcom with an anniversary edition. 21 00:00:54,810 --> 00:00:56,520 Applause substantial into. 22 00:01:05,209 --> 00:01:06,469 OK, so thank you very much for the 23 00:01:06,470 --> 00:01:07,399 introduction. 24 00:01:07,400 --> 00:01:09,259 It's great to be back. 25 00:01:09,260 --> 00:01:11,119 And I'm very glad that no one is leaving 26 00:01:11,120 --> 00:01:13,309 right now because we're presenting 27 00:01:13,310 --> 00:01:14,409 a new vulnerability. 28 00:01:14,410 --> 00:01:15,649 And it's a celebration, too, right? 29 00:01:15,650 --> 00:01:16,819 That is kind of old. 30 00:01:18,410 --> 00:01:19,639 The attack has a name. 31 00:01:19,640 --> 00:01:21,949 It has a Web page and it has even a logo. 32 00:01:21,950 --> 00:01:23,989 And having said that, I am really glad 33 00:01:23,990 --> 00:01:25,370 that no one's leaving the 34 00:01:26,690 --> 00:01:28,040 room right now as well. 35 00:01:29,720 --> 00:01:32,269 The talk will be unbreaking tearless. 36 00:01:32,270 --> 00:01:34,519 And so pretty much everyone here in this 37 00:01:34,520 --> 00:01:36,589 room uses tearless, 38 00:01:36,590 --> 00:01:38,719 probably at this very at this very 39 00:01:38,720 --> 00:01:41,059 moment while your mobile 40 00:01:41,060 --> 00:01:43,159 phone is checking whatever is 41 00:01:43,160 --> 00:01:45,669 going on on Twitter or Facebook. 42 00:01:45,670 --> 00:01:47,869 So over HDP s or you're checking your 43 00:01:47,870 --> 00:01:49,249 emails and stuff like that. 44 00:01:49,250 --> 00:01:50,159 Right. 45 00:01:50,160 --> 00:01:51,160 So. 46 00:01:51,730 --> 00:01:53,129 So tell us this. 47 00:01:53,130 --> 00:01:54,230 It's really important. 48 00:01:55,490 --> 00:01:57,589 The drone attack has 15 offers and 49 00:01:57,590 --> 00:01:59,029 they obviously couldn't. 50 00:01:59,030 --> 00:02:00,349 Couldn't all come here. 51 00:02:00,350 --> 00:02:02,479 The six of us here is like the 52 00:02:02,480 --> 00:02:05,059 most people that got on 53 00:02:05,060 --> 00:02:06,730 on like on 54 00:02:07,850 --> 00:02:09,409 on on a single picture. 55 00:02:09,410 --> 00:02:11,509 And if you look closely, we are very 56 00:02:11,510 --> 00:02:13,579 happy to have received the 57 00:02:13,580 --> 00:02:15,679 first PONI award 58 00:02:15,680 --> 00:02:17,599 for the best cryptographic attack in 59 00:02:17,600 --> 00:02:19,759 2016, said, we are we are really 60 00:02:19,760 --> 00:02:22,000 happy about this, but. 61 00:02:23,120 --> 00:02:24,919 So when we talk about SSL version two, 62 00:02:24,920 --> 00:02:26,819 what is what is really SSL version two? 63 00:02:26,820 --> 00:02:28,099 So SSL version two was 64 00:02:29,150 --> 00:02:31,729 was created in 1995 65 00:02:31,730 --> 00:02:34,759 and it was immediately broken in 1995. 66 00:02:34,760 --> 00:02:36,349 Right. So in the same year, just a few 67 00:02:36,350 --> 00:02:38,059 months later. So how did the Internet 68 00:02:38,060 --> 00:02:40,309 look like during these ages? 69 00:02:40,310 --> 00:02:41,929 Pretty. Pretty. Pretty much like this. 70 00:02:41,930 --> 00:02:44,079 Right. This is the Internet of 71 00:02:44,080 --> 00:02:46,219 of the 1990s with 72 00:02:46,220 --> 00:02:48,649 some cryptographic primitives like DNS 73 00:02:48,650 --> 00:02:50,719 and RC for an RC two 74 00:02:50,720 --> 00:02:51,769 and so on and so on. 75 00:02:51,770 --> 00:02:53,209 Most of them are broken. 76 00:02:53,210 --> 00:02:55,429 And there's also some really interesting 77 00:02:55,430 --> 00:02:57,679 things like here, export 40 78 00:02:57,680 --> 00:02:58,609 bits, something like this. 79 00:02:58,610 --> 00:02:59,610 Right. That's 80 00:03:00,800 --> 00:03:02,839 like a cipher, a primitive that was 81 00:03:02,840 --> 00:03:05,639 created because of like politics. 82 00:03:05,640 --> 00:03:08,149 Right. Cryptographic regulations 83 00:03:08,150 --> 00:03:10,489 in the 90s sent that you're only 84 00:03:10,490 --> 00:03:12,919 supposed to export crypto 85 00:03:12,920 --> 00:03:15,289 cryptography with a certain strength, 86 00:03:15,290 --> 00:03:16,879 with a certain maximum strength out of 87 00:03:16,880 --> 00:03:19,079 the US. And this is what we see here. 88 00:03:19,080 --> 00:03:20,029 Right. 89 00:03:20,030 --> 00:03:22,279 So in 1995, as this aversion to 90 00:03:22,280 --> 00:03:23,599 immediately died. 91 00:03:23,600 --> 00:03:26,269 And the reason for that is that 92 00:03:26,270 --> 00:03:28,399 like the creators of SSL version 93 00:03:28,400 --> 00:03:30,199 two, it was published by Netscape. 94 00:03:31,930 --> 00:03:34,099 They they didn't authenticate the 95 00:03:34,100 --> 00:03:36,259 handshake. So an active man 96 00:03:36,260 --> 00:03:38,449 in the middle could just intercept 97 00:03:38,450 --> 00:03:40,789 the handshake and force 98 00:03:40,790 --> 00:03:42,739 you and the server you as a client and 99 00:03:42,740 --> 00:03:45,559 the server to negotiate a very weak 100 00:03:45,560 --> 00:03:46,729 encryption. 101 00:03:46,730 --> 00:03:48,049 And there was no fix for that. 102 00:03:48,050 --> 00:03:50,239 So this is nothing that you could 103 00:03:50,240 --> 00:03:52,250 fix off because it was a protocol issue. 104 00:03:53,390 --> 00:03:55,819 And so, therefore, in 1996, 105 00:03:55,820 --> 00:03:58,189 one year later, they came up with SSL 106 00:03:58,190 --> 00:04:01,039 version three, which is still the basis 107 00:04:01,040 --> 00:04:03,289 on the protocol level for the tearless 108 00:04:03,290 --> 00:04:05,779 that we see that we see today 109 00:04:05,780 --> 00:04:07,399 and that we use every day. 110 00:04:07,400 --> 00:04:08,299 Right. 111 00:04:08,300 --> 00:04:10,429 So now you could say, OK, SS Aubuchon two 112 00:04:10,430 --> 00:04:13,459 was published in 1995 113 00:04:13,460 --> 00:04:16,009 and it was broken in 1995. 114 00:04:16,010 --> 00:04:18,139 No one's no one's ever gonna use 115 00:04:18,140 --> 00:04:19,749 this right now. 116 00:04:19,750 --> 00:04:20,839 I've got some data for you. 117 00:04:22,130 --> 00:04:24,619 So this is the Internet white 118 00:04:24,620 --> 00:04:26,859 scan of the whole IP 119 00:04:26,860 --> 00:04:28,099 before Internet. 120 00:04:28,100 --> 00:04:30,649 In February 2016. 121 00:04:30,650 --> 00:04:31,969 And what do you see here? Is not the 122 00:04:31,970 --> 00:04:34,849 amount of holes. That's the percentage 123 00:04:34,850 --> 00:04:37,519 of all the tearless 124 00:04:37,520 --> 00:04:39,170 and SSL supporting 125 00:04:40,250 --> 00:04:42,199 systems in on the Internet. 126 00:04:42,200 --> 00:04:44,059 And there you see, for example, that 28 127 00:04:44,060 --> 00:04:46,579 percent of all service 128 00:04:46,580 --> 00:04:48,589 listening on Port 25, which is assumptive 129 00:04:48,590 --> 00:04:50,659 p use SSL version 130 00:04:50,660 --> 00:04:53,089 two, which is really, really strange. 131 00:04:53,090 --> 00:04:55,279 Right. I'll I'll I'll come later 132 00:04:55,280 --> 00:04:57,229 to this point. What was the reason for 133 00:04:57,230 --> 00:04:58,999 that. And even for 134 00:05:00,470 --> 00:05:01,379 for HTP. 135 00:05:01,380 --> 00:05:04,039 S support for for three, we still see 17 136 00:05:04,040 --> 00:05:06,169 percent of all the hosts 137 00:05:06,170 --> 00:05:08,259 out there directly support as 138 00:05:08,260 --> 00:05:10,159 a solution to. Which is really, really 139 00:05:10,160 --> 00:05:11,269 strange. Right. 140 00:05:11,270 --> 00:05:12,209 So you could even say. 141 00:05:12,210 --> 00:05:14,629 Right. These all dinosaurs, all 142 00:05:14,630 --> 00:05:16,609 are coming back somehow 143 00:05:18,530 --> 00:05:19,469 to haunt us. 144 00:05:19,470 --> 00:05:20,739 Ah ah ah ah. 145 00:05:20,740 --> 00:05:21,799 See users on the Internet. 146 00:05:21,800 --> 00:05:22,800 Right. 147 00:05:23,510 --> 00:05:24,510 Okay. 148 00:05:26,120 --> 00:05:27,559 So to give you an overview, what is 149 00:05:27,560 --> 00:05:28,909 thrown all about. 150 00:05:28,910 --> 00:05:31,369 So drawn is a fairly sophisticated 151 00:05:31,370 --> 00:05:32,559 exploit chain. 152 00:05:32,560 --> 00:05:33,859 And I will. 153 00:05:33,860 --> 00:05:36,169 It will take me some time to to explain 154 00:05:36,170 --> 00:05:37,489 all the puzzle pieces. 155 00:05:37,490 --> 00:05:39,439 So therefore, this is just a short 156 00:05:39,440 --> 00:05:41,509 overview of that, 157 00:05:41,510 --> 00:05:43,189 like the requirements that an attacker 158 00:05:43,190 --> 00:05:45,289 needs to do in order to 159 00:05:45,290 --> 00:05:47,679 in order to to run a drone exploit. 160 00:05:48,740 --> 00:05:51,139 So first of all, we can break one in 1000 161 00:05:51,140 --> 00:05:53,029 tearless connections. So not everyone, 162 00:05:53,030 --> 00:05:54,589 not every tailless connection, but only 163 00:05:54,590 --> 00:05:55,790 one in 1000. 164 00:05:56,960 --> 00:05:58,379 That basically means. 165 00:05:58,380 --> 00:06:00,559 So in order to break 166 00:06:00,560 --> 00:06:02,629 one of your tearless connections, 167 00:06:02,630 --> 00:06:04,239 the attacker has on average. 168 00:06:04,240 --> 00:06:06,489 To collect 1000 tearless 169 00:06:06,490 --> 00:06:07,490 connections from you. 170 00:06:08,500 --> 00:06:10,299 These can be connections that were 171 00:06:10,300 --> 00:06:12,579 recorded long before Brown 172 00:06:12,580 --> 00:06:13,719 was No. Right. 173 00:06:13,720 --> 00:06:15,369 So we're not talking about an active 174 00:06:15,370 --> 00:06:17,439 attack. It's a passive attack. 175 00:06:17,440 --> 00:06:19,129 And so, therefore, just clicking we 176 00:06:19,130 --> 00:06:21,299 caught in your wireshark 177 00:06:21,300 --> 00:06:22,779 is already sufficient. 178 00:06:22,780 --> 00:06:25,539 And you did this like on a Congress 179 00:06:25,540 --> 00:06:26,859 three or four years ago. 180 00:06:26,860 --> 00:06:28,959 You can break the tearless connections 181 00:06:28,960 --> 00:06:31,179 that you recorded back then, maybe under 182 00:06:31,180 --> 00:06:32,529 certain conditions right now. 183 00:06:34,420 --> 00:06:35,589 OK. 184 00:06:35,590 --> 00:06:37,209 It doesn't come for free. 185 00:06:37,210 --> 00:06:39,069 So we need to perform to to the 50 186 00:06:39,070 --> 00:06:41,829 encryptions, which is which is a lot. 187 00:06:41,830 --> 00:06:43,899 We can do this, but we need Rava 188 00:06:43,900 --> 00:06:46,089 beefy hardware in order in order to do 189 00:06:46,090 --> 00:06:48,309 this. And there's one more requirement. 190 00:06:48,310 --> 00:06:51,309 We need to do around 40000 connections 191 00:06:51,310 --> 00:06:53,739 to that, to that server 192 00:06:53,740 --> 00:06:55,539 that supports SSL wishing to. 193 00:06:55,540 --> 00:06:57,369 Right. So we need one server that 194 00:06:57,370 --> 00:06:59,049 supports SSL version two. 195 00:06:59,050 --> 00:07:01,719 And one very important thing is that 196 00:07:01,720 --> 00:07:04,089 clients don't support SSL 197 00:07:04,090 --> 00:07:06,279 version two for for very long 198 00:07:06,280 --> 00:07:08,379 time. So the last browser that supported 199 00:07:08,380 --> 00:07:11,469 SSL version two was Internet Explorer six 200 00:07:11,470 --> 00:07:12,699 on XP. 201 00:07:12,700 --> 00:07:15,039 Right. And even Internet Explorer six 202 00:07:15,040 --> 00:07:17,619 would always prefer SSL version three. 203 00:07:17,620 --> 00:07:19,419 Right. So if there is a way to to to 204 00:07:19,420 --> 00:07:21,519 negotiate SSL version three, it 205 00:07:21,520 --> 00:07:24,359 would it would also always use that. 206 00:07:24,360 --> 00:07:26,799 So I'm sorry. 207 00:07:26,800 --> 00:07:28,629 We are really breaking tearless 208 00:07:28,630 --> 00:07:30,459 connections. So the connections that 209 00:07:30,460 --> 00:07:32,829 Europe very recent to 210 00:07:32,830 --> 00:07:35,409 tearless client does right now 211 00:07:35,410 --> 00:07:37,479 under the condition that the same server 212 00:07:37,480 --> 00:07:39,129 is supporting SSL Washington, which is 213 00:07:39,130 --> 00:07:40,089 really strange. 214 00:07:40,090 --> 00:07:42,549 Right. So we break tearless 215 00:07:42,550 --> 00:07:43,550 using SSL. 216 00:07:44,890 --> 00:07:45,890 Okay. 217 00:07:46,600 --> 00:07:48,669 So we did an exploit. 218 00:07:48,670 --> 00:07:50,979 And also we put a lot of effort 219 00:07:50,980 --> 00:07:52,809 into optimizing the attack. 220 00:07:52,810 --> 00:07:55,179 And the best thing that we could do was 221 00:07:55,180 --> 00:07:57,429 breaking a single tearless connection on 222 00:07:57,430 --> 00:07:59,709 Amazon. Easy to for 223 00:07:59,710 --> 00:08:00,939 440 U.S. 224 00:08:00,940 --> 00:08:02,439 dollars. So which is pretty. 225 00:08:02,440 --> 00:08:04,769 Right. So if everyone here gives 226 00:08:04,770 --> 00:08:06,849 like maybe 50 cents or so, that 227 00:08:06,850 --> 00:08:08,199 will be already sufficient to break a 228 00:08:08,200 --> 00:08:09,849 single tearless connection. 229 00:08:09,850 --> 00:08:11,949 So I don't need to break a lot of 230 00:08:11,950 --> 00:08:13,719 tearless connection. 231 00:08:13,720 --> 00:08:16,629 I just need to break a single 232 00:08:16,630 --> 00:08:18,699 tearless connection that your 233 00:08:19,930 --> 00:08:22,179 pop three client does every 234 00:08:22,180 --> 00:08:24,369 minute or so to get your email because 235 00:08:24,370 --> 00:08:26,549 they're you your password is is 236 00:08:26,550 --> 00:08:29,079 in there. And if you get your password 237 00:08:29,080 --> 00:08:31,229 right, we can break all the residual. 238 00:08:31,230 --> 00:08:32,149 Right. 239 00:08:32,150 --> 00:08:34,589 So breaking just a single one is 240 00:08:34,590 --> 00:08:35,949 sufficient in most cases. 241 00:08:38,130 --> 00:08:40,379 OK. I said there's a lot of 242 00:08:40,380 --> 00:08:42,509 puzzle pieces that we that we need to 243 00:08:42,510 --> 00:08:44,779 do. And I tried to cluster them to 244 00:08:44,780 --> 00:08:47,219 two to make them more digestible. 245 00:08:47,220 --> 00:08:49,349 So the first thing that I'm going to 246 00:08:49,350 --> 00:08:51,239 talk about is it's a special attack that 247 00:08:51,240 --> 00:08:53,339 I've already talked about two years ago. 248 00:08:53,340 --> 00:08:55,529 I will just go briefly into it, if you're 249 00:08:55,530 --> 00:08:57,539 interested, more into the details of 250 00:08:57,540 --> 00:08:58,919 placing bathetic. 251 00:08:58,920 --> 00:09:01,049 Just look, watch or more from our talk 252 00:09:01,050 --> 00:09:02,580 in 31 C three. 253 00:09:03,900 --> 00:09:06,029 I will show you a new protocol flaw 254 00:09:06,030 --> 00:09:07,259 in SSL version two. 255 00:09:07,260 --> 00:09:09,719 And I need to explain what is it with 256 00:09:09,720 --> 00:09:11,549 a 40 bit expert ciphers. 257 00:09:11,550 --> 00:09:13,679 So when we combine these three 258 00:09:13,680 --> 00:09:16,169 puzzle pieces, we have a practical attack 259 00:09:16,170 --> 00:09:18,299 against SSL version two, which 260 00:09:18,300 --> 00:09:20,639 is not relevant at all because no 261 00:09:20,640 --> 00:09:22,499 one is speaking as a single version two 262 00:09:22,500 --> 00:09:23,700 on the Internet anymore. 263 00:09:25,410 --> 00:09:27,329 We just have servers that support it 264 00:09:27,330 --> 00:09:29,489 generally, but usually this we couldn't 265 00:09:29,490 --> 00:09:31,559 find any any client that still 266 00:09:31,560 --> 00:09:32,690 negotiates SSL wishing. 267 00:09:33,880 --> 00:09:35,109 Okay. 268 00:09:35,110 --> 00:09:36,749 The second thing that we have to look at 269 00:09:36,750 --> 00:09:38,819 is shared keys 270 00:09:38,820 --> 00:09:40,919 among the different SSL until 271 00:09:40,920 --> 00:09:43,169 s versions. So when you set up an 272 00:09:43,170 --> 00:09:45,279 SSL server and it 273 00:09:45,280 --> 00:09:47,519 supports as a solution to version three 274 00:09:47,520 --> 00:09:49,899 and tearless 1.0 up to 275 00:09:49,900 --> 00:09:51,989 one to two, it will always 276 00:09:51,990 --> 00:09:53,999 use the same RSA key here. 277 00:09:54,000 --> 00:09:55,949 Right. And when we take this into 278 00:09:55,950 --> 00:09:56,950 account. 279 00:09:57,740 --> 00:09:59,329 All of a sudden, drone becomes a 280 00:09:59,330 --> 00:10:01,639 practical attack against many 281 00:10:01,640 --> 00:10:03,109 tearless servers. 282 00:10:03,110 --> 00:10:04,879 Right. It's practical in an academic 283 00:10:04,880 --> 00:10:07,159 sense. It still means it's an expensive 284 00:10:07,160 --> 00:10:08,959 attack. But we can do it right. 285 00:10:08,960 --> 00:10:10,909 We can afford it. We all here can afford 286 00:10:10,910 --> 00:10:11,910 it. 287 00:10:12,100 --> 00:10:14,399 And then we have two implementation 288 00:10:14,400 --> 00:10:16,639 errors. So all of the above 289 00:10:17,840 --> 00:10:20,449 practically means that we can attack 290 00:10:20,450 --> 00:10:22,579 every SSL wishing to implementation 291 00:10:22,580 --> 00:10:24,169 that is out there. 292 00:10:24,170 --> 00:10:26,299 Now, here we are looking into 293 00:10:26,300 --> 00:10:28,369 two implementation errors in open 294 00:10:28,370 --> 00:10:30,889 SSL. And if we take which we combine 295 00:10:30,890 --> 00:10:33,229 these with the already existing drone 296 00:10:33,230 --> 00:10:35,389 attack, we all of a sudden get 297 00:10:35,390 --> 00:10:36,499 a trivial attack. 298 00:10:36,500 --> 00:10:38,419 Really trivial. That means it takes 299 00:10:38,420 --> 00:10:40,759 minutes on this laptop against 300 00:10:40,760 --> 00:10:42,110 a lot of tearless servers. 301 00:10:44,260 --> 00:10:45,260 OK. 302 00:10:45,560 --> 00:10:47,929 So let's start with Oblation Bihar's 303 00:10:47,930 --> 00:10:49,699 1998 attack. 304 00:10:49,700 --> 00:10:51,889 And before I start with that, I just 305 00:10:51,890 --> 00:10:54,379 want to quickly repeat 306 00:10:54,380 --> 00:10:57,319 the RSA based key exchange 307 00:10:57,320 --> 00:10:58,969 for tearless. 308 00:10:58,970 --> 00:11:01,159 So there's 309 00:11:01,160 --> 00:11:04,669 various ways of negotiating 310 00:11:04,670 --> 00:11:05,869 like a key. 311 00:11:05,870 --> 00:11:07,999 And when I see a key, it always means 312 00:11:08,000 --> 00:11:09,109 a symmetric key. 313 00:11:09,110 --> 00:11:11,329 Right. So as a metric encryption, 314 00:11:11,330 --> 00:11:12,769 for example, with RSA is pretty 315 00:11:12,770 --> 00:11:13,729 expensive. 316 00:11:13,730 --> 00:11:15,229 So therefore, we just do the key 317 00:11:15,230 --> 00:11:17,359 exchange, like we 318 00:11:17,360 --> 00:11:19,429 exchange a symmetric key over RSA, 319 00:11:19,430 --> 00:11:22,339 which is not that not that much data. 320 00:11:22,340 --> 00:11:24,439 And then the actual content that will be 321 00:11:24,440 --> 00:11:26,509 transferred over the SSL 322 00:11:26,510 --> 00:11:28,789 or Quiles connection. 323 00:11:28,790 --> 00:11:30,949 This will use a yes or triple deaths 324 00:11:30,950 --> 00:11:33,079 or deaths or C4 or something like 325 00:11:33,080 --> 00:11:35,209 this. And what we are looking at is 326 00:11:35,210 --> 00:11:37,369 right now only the part where we 327 00:11:37,370 --> 00:11:39,319 negotiate this key for this symmetric 328 00:11:39,320 --> 00:11:40,729 encryption. 329 00:11:40,730 --> 00:11:42,319 So we have a tearless client, we have a 330 00:11:42,320 --> 00:11:43,639 tailor server. 331 00:11:43,640 --> 00:11:45,799 The tearless client always starts with 332 00:11:45,800 --> 00:11:47,029 a client. Hello. 333 00:11:47,030 --> 00:11:49,849 And it contains a client random number. 334 00:11:49,850 --> 00:11:52,159 This will be like this changes 335 00:11:52,160 --> 00:11:53,389 with every request. 336 00:11:53,390 --> 00:11:55,039 So the client changes this number with 337 00:11:55,040 --> 00:11:56,959 every request and it will be sent in 338 00:11:56,960 --> 00:11:58,789 clear text so the attacker knows this. 339 00:12:00,080 --> 00:12:02,179 The second message, the response 340 00:12:02,180 --> 00:12:03,619 of the tearless server will be the 341 00:12:03,620 --> 00:12:04,819 server. Hello. 342 00:12:04,820 --> 00:12:06,979 It will generate 343 00:12:06,980 --> 00:12:08,209 a random number as well. 344 00:12:08,210 --> 00:12:09,559 It's a server random. 345 00:12:09,560 --> 00:12:11,929 And this will also change with every 346 00:12:11,930 --> 00:12:13,279 with every new connection. 347 00:12:13,280 --> 00:12:15,229 And it's also sending clear text so the 348 00:12:15,230 --> 00:12:17,099 attacker knows claimed random and server 349 00:12:17,100 --> 00:12:18,079 random. 350 00:12:18,080 --> 00:12:20,809 And then it also sends this certificate 351 00:12:20,810 --> 00:12:23,589 that you buy for Comodo or 352 00:12:23,590 --> 00:12:25,579 at Comodo or even that lets encrypt or so 353 00:12:25,580 --> 00:12:26,809 you get it for free. 354 00:12:26,810 --> 00:12:28,849 And in this very cert, there's an RSA 355 00:12:28,850 --> 00:12:30,169 public key. 356 00:12:30,170 --> 00:12:32,359 Right. And this is a public he will 357 00:12:32,360 --> 00:12:35,299 be also sent with a certificate. 358 00:12:35,300 --> 00:12:37,159 And with the next message, the client key 359 00:12:37,160 --> 00:12:38,729 exchange that he'll? 360 00:12:38,730 --> 00:12:40,849 S client generates a thing that 361 00:12:40,850 --> 00:12:42,409 is called a pre massive secret. 362 00:12:43,790 --> 00:12:45,889 And this is the only part that is really 363 00:12:45,890 --> 00:12:47,569 secret in this whole in this whole 364 00:12:47,570 --> 00:12:48,649 exchange. 365 00:12:48,650 --> 00:12:50,989 It will not send this Prima's a secret 366 00:12:50,990 --> 00:12:53,089 in clear. But it will encrypted with 367 00:12:53,090 --> 00:12:55,189 RSA and the key from the 368 00:12:55,190 --> 00:12:56,839 certificate that it just received from 369 00:12:56,840 --> 00:12:58,820 the server and sent this over. 370 00:13:00,190 --> 00:13:01,739 And the next step, and this is a very 371 00:13:01,740 --> 00:13:04,259 important step, that he'll a server 372 00:13:04,260 --> 00:13:06,359 decrypts the prematch, the secret that 373 00:13:06,360 --> 00:13:08,699 it just received, and from this pretty 374 00:13:08,700 --> 00:13:11,069 massive secret, both the client 375 00:13:11,070 --> 00:13:13,439 and the server can generate the same 376 00:13:13,440 --> 00:13:14,909 symmetric key. 377 00:13:14,910 --> 00:13:17,639 OK, so that means 378 00:13:17,640 --> 00:13:19,859 the the this the 379 00:13:19,860 --> 00:13:21,959 attacker knows the client random. 380 00:13:21,960 --> 00:13:23,969 It knows the server random, and it gets 381 00:13:23,970 --> 00:13:26,209 an encrypted version of the pre premises 382 00:13:26,210 --> 00:13:27,329 secret. 383 00:13:27,330 --> 00:13:29,399 And if the attacker can can can 384 00:13:29,400 --> 00:13:31,439 decrypt this, Prima's a secret. 385 00:13:31,440 --> 00:13:33,629 He knows the massive secret, this 386 00:13:33,630 --> 00:13:35,879 symmetric key that is used for RC, for 387 00:13:35,880 --> 00:13:37,959 ice and stuff like that. 388 00:13:37,960 --> 00:13:39,929 Right. So this is the Holy Grail that we 389 00:13:39,930 --> 00:13:41,769 want to break right now and blacken. 390 00:13:41,770 --> 00:13:44,119 BEHÇET achieves exactly this. 391 00:13:44,120 --> 00:13:45,299 Right. So that's important. 392 00:13:46,980 --> 00:13:48,629 What I need to mention here is this 393 00:13:48,630 --> 00:13:50,189 decryption can fail. 394 00:13:50,190 --> 00:13:52,949 So when the attacker sends, 395 00:13:52,950 --> 00:13:55,269 let's say, an arbitrary ciphertext, 396 00:13:55,270 --> 00:13:57,719 some some drunk data or so, 397 00:13:57,720 --> 00:14:00,119 the server first has to decrypt 398 00:14:00,120 --> 00:14:02,219 this ciphertext in order to find out 399 00:14:02,220 --> 00:14:04,669 whether this is a valid premises, 400 00:14:04,670 --> 00:14:05,670 secret or not. 401 00:14:07,150 --> 00:14:08,150 OK. 402 00:14:08,980 --> 00:14:10,949 So in order to conduct the blasphemous 403 00:14:10,950 --> 00:14:13,419 attack, we need an oracle, so 404 00:14:13,420 --> 00:14:15,969 that's a cryptographic term 405 00:14:15,970 --> 00:14:18,759 for nothing else than a service 406 00:14:18,760 --> 00:14:21,789 that accepts an arbitrary ciphertext 407 00:14:21,790 --> 00:14:24,009 and it will decrypt this cipher text. 408 00:14:24,010 --> 00:14:26,649 So it needs to have the RSA private key 409 00:14:26,650 --> 00:14:28,869 and it responds with one or zero. 410 00:14:28,870 --> 00:14:31,119 So true or false, depending 411 00:14:31,120 --> 00:14:32,859 on the successful decryption. 412 00:14:32,860 --> 00:14:34,419 Right. So if the decryption was 413 00:14:34,420 --> 00:14:36,639 successful and the premises secret 414 00:14:36,640 --> 00:14:38,949 looks somehow valid, 415 00:14:38,950 --> 00:14:40,390 it looks somehow 416 00:14:42,160 --> 00:14:43,989 then it will say, OK, it's true or 417 00:14:43,990 --> 00:14:44,889 otherwise it's false. 418 00:14:44,890 --> 00:14:46,839 So we only get one bit of information 419 00:14:46,840 --> 00:14:48,519 from from this oracle. 420 00:14:48,520 --> 00:14:51,189 So we have a client here and a server. 421 00:14:51,190 --> 00:14:53,259 We have an attacker that 422 00:14:53,260 --> 00:14:55,269 eavesdrops on this connection. 423 00:14:55,270 --> 00:14:57,379 And then it changes 424 00:14:57,380 --> 00:14:59,529 certain parameters of this connection and 425 00:14:59,530 --> 00:15:01,179 sent it over to the Oracle. 426 00:15:01,180 --> 00:15:02,470 The Oracle decrypted 427 00:15:03,780 --> 00:15:05,819 parses it and then says, OK, decryption 428 00:15:05,820 --> 00:15:08,139 or successful or or not. 429 00:15:08,140 --> 00:15:09,309 That's the only information that the 430 00:15:09,310 --> 00:15:11,589 attacker gets gets from the Oracle. 431 00:15:11,590 --> 00:15:13,209 So every time the Oracle answers with a 432 00:15:13,210 --> 00:15:15,519 one or withdrew, 433 00:15:15,520 --> 00:15:17,769 the attacker learns a tiny fraction 434 00:15:17,770 --> 00:15:20,109 of the RSA ciphertext. 435 00:15:20,110 --> 00:15:22,089 So there's a mathematical formula where 436 00:15:22,090 --> 00:15:23,619 you could put everything in. 437 00:15:23,620 --> 00:15:25,840 And if the attacker only does this, 438 00:15:26,860 --> 00:15:28,689 let's say, a few thousand times or so, he 439 00:15:28,690 --> 00:15:30,429 can learn the full ciphertext. 440 00:15:30,430 --> 00:15:32,439 He doesn't get the RSA private key. 441 00:15:32,440 --> 00:15:34,719 We only get like we only 442 00:15:34,720 --> 00:15:37,329 can decrypt this. This the single RSA 443 00:15:37,330 --> 00:15:38,330 ciphertext. 444 00:15:40,390 --> 00:15:42,789 OK, so 445 00:15:42,790 --> 00:15:45,129 in the original paper of Dacian Bahah 446 00:15:45,130 --> 00:15:47,229 from 1998, he 447 00:15:47,230 --> 00:15:49,419 was exploiting the fact that 448 00:15:49,420 --> 00:15:51,729 common tearless implementations, 449 00:15:51,730 --> 00:15:54,099 what would like they had like 450 00:15:54,100 --> 00:15:56,349 an explicit error message for this 451 00:15:56,350 --> 00:15:58,539 type of decryption failure, 452 00:15:58,540 --> 00:15:59,889 which is really bad. 453 00:15:59,890 --> 00:16:02,199 And so they didn't actually 454 00:16:02,200 --> 00:16:04,659 fix the the SSL 455 00:16:04,660 --> 00:16:06,519 or the tearless standard. 456 00:16:06,520 --> 00:16:07,809 They just said, okay, here's an 457 00:16:07,810 --> 00:16:09,839 implementation fix so that the blazing 458 00:16:09,840 --> 00:16:11,979 the high tech won't work anymore. 459 00:16:11,980 --> 00:16:13,269 And it works like this. 460 00:16:13,270 --> 00:16:15,819 So we pretend that the decrypted 461 00:16:15,820 --> 00:16:17,199 prematch, the secret that we have 462 00:16:17,200 --> 00:16:20,019 received was correct 463 00:16:20,020 --> 00:16:22,059 and we proceed with a random pre massive 464 00:16:22,060 --> 00:16:23,339 secret. 465 00:16:23,340 --> 00:16:25,629 So in case that the 466 00:16:25,630 --> 00:16:27,549 the the ciphertext that we have just 467 00:16:27,550 --> 00:16:29,739 received was in mail, it would 468 00:16:29,740 --> 00:16:31,959 just generate a random prima's a secret 469 00:16:31,960 --> 00:16:34,239 and continue with with with the flow. 470 00:16:34,240 --> 00:16:36,339 And this will obviously lead 471 00:16:36,340 --> 00:16:38,529 us lead to some later Iran, because 472 00:16:38,530 --> 00:16:40,659 the symmetric key that comes out here is 473 00:16:40,660 --> 00:16:42,549 different for the client and the server. 474 00:16:42,550 --> 00:16:44,739 So they simply speak with a different key 475 00:16:44,740 --> 00:16:45,969 and can decrypt each other. 476 00:16:45,970 --> 00:16:47,559 And then it comes to an arrow. 477 00:16:47,560 --> 00:16:48,579 Right. 478 00:16:48,580 --> 00:16:50,949 So this looks like this. 479 00:16:50,950 --> 00:16:53,259 So the server will decrypt the premises 480 00:16:53,260 --> 00:16:54,159 secret. 481 00:16:54,160 --> 00:16:56,259 He will always generate a random, 482 00:16:56,260 --> 00:16:57,639 pretty massive secret. 483 00:16:57,640 --> 00:16:59,769 And then depending of whether 484 00:16:59,770 --> 00:17:01,389 the decryption 485 00:17:02,410 --> 00:17:03,759 succeeded or not, 486 00:17:04,780 --> 00:17:06,939 when it succeeded, it will proceed with 487 00:17:06,940 --> 00:17:09,459 a decrypted Premer premise. 488 00:17:09,460 --> 00:17:11,229 And in the case where the decryption 489 00:17:11,230 --> 00:17:13,479 failed, it will proceed with a random 490 00:17:13,480 --> 00:17:16,449 premises secret that it just generated. 491 00:17:16,450 --> 00:17:17,559 And so 492 00:17:19,000 --> 00:17:21,338 this makes all the implementations 493 00:17:21,339 --> 00:17:23,049 that we looked at like it's 494 00:17:23,050 --> 00:17:25,629 indistinguishable, whether the decryption 495 00:17:25,630 --> 00:17:27,848 succeeded or whether it failed. 496 00:17:27,849 --> 00:17:29,439 So it's an implementation fix that is 497 00:17:29,440 --> 00:17:30,940 written in the in the AFC. 498 00:17:35,080 --> 00:17:37,329 Now, we exploit that this very 499 00:17:37,330 --> 00:17:39,309 countermeasure for oblation bahah attack 500 00:17:39,310 --> 00:17:40,869 for blessin because attack in order to 501 00:17:40,870 --> 00:17:43,029 conduct a new bludgeon Barkhouse attack. 502 00:17:43,030 --> 00:17:44,140 Right. And it works like this. 503 00:17:45,460 --> 00:17:46,460 OK. 504 00:17:49,390 --> 00:17:51,849 So let's look at the SSL Worsham to 505 00:17:51,850 --> 00:17:53,589 protocol. It changes. 506 00:17:53,590 --> 00:17:55,689 It's it's it's slightly different 507 00:17:55,690 --> 00:17:57,789 from SSL version three, but it doesn't 508 00:17:57,790 --> 00:17:59,559 doesn't really matter. So we also have a 509 00:17:59,560 --> 00:18:01,149 client. Hello. We also have our server. 510 00:18:01,150 --> 00:18:03,309 Hello. We also have this kind of 511 00:18:03,310 --> 00:18:04,419 client key exchange. 512 00:18:04,420 --> 00:18:06,579 It has just a different name 513 00:18:06,580 --> 00:18:08,829 where we send this symmetric 514 00:18:08,830 --> 00:18:11,679 key that was generated by the client. 515 00:18:11,680 --> 00:18:13,900 And then both would 516 00:18:15,070 --> 00:18:16,869 then both would generate those symmetric 517 00:18:16,870 --> 00:18:18,129 keys. 518 00:18:18,130 --> 00:18:20,889 And what is interesting here is 519 00:18:20,890 --> 00:18:23,559 that the first one that responds 520 00:18:23,560 --> 00:18:25,269 with an encrypted message will be the 521 00:18:25,270 --> 00:18:26,270 server. 522 00:18:27,370 --> 00:18:30,099 And this has very one 523 00:18:30,100 --> 00:18:32,199 very important implication. 524 00:18:32,200 --> 00:18:34,389 That means the 525 00:18:34,390 --> 00:18:36,559 client gets one ciphertext 526 00:18:36,560 --> 00:18:38,619 or the server verify is an encrypted 527 00:18:38,620 --> 00:18:40,929 message with a key. 528 00:18:40,930 --> 00:18:43,029 So with that, Masaaki, that both client 529 00:18:43,030 --> 00:18:44,829 and server should know better by now. 530 00:18:46,300 --> 00:18:48,579 And the client gets 531 00:18:48,580 --> 00:18:51,009 this message without proving 532 00:18:51,010 --> 00:18:53,289 that it has the same symmetric key 533 00:18:53,290 --> 00:18:55,749 in SSL version three and and tearless 534 00:18:55,750 --> 00:18:56,829 this is different. 535 00:18:56,830 --> 00:18:59,139 So this this 536 00:18:59,140 --> 00:19:01,689 message here will only be sent 537 00:19:01,690 --> 00:19:03,429 after the client proved with with a 538 00:19:03,430 --> 00:19:05,289 finished message that he possesses the 539 00:19:05,290 --> 00:19:06,299 same symmetric key. 540 00:19:07,330 --> 00:19:09,729 So the attacker gets one ciphertext 541 00:19:09,730 --> 00:19:11,689 that is encrypted with an unknown key 542 00:19:11,690 --> 00:19:13,119 because we don't know the. 543 00:19:13,120 --> 00:19:14,120 We don't know the key yet. 544 00:19:15,850 --> 00:19:18,189 The question and please accept 545 00:19:18,190 --> 00:19:21,459 it, that this is now an important 546 00:19:21,460 --> 00:19:22,839 an important question that we need to 547 00:19:22,840 --> 00:19:24,819 raise. And I'll explain it in a lot in 548 00:19:24,820 --> 00:19:26,859 the next two slides. 549 00:19:26,860 --> 00:19:29,229 Can we learn this key so we get a cipher 550 00:19:29,230 --> 00:19:30,519 text? 551 00:19:30,520 --> 00:19:32,589 And the question is, can we learn the key 552 00:19:32,590 --> 00:19:34,630 that was used to encrypt that message? 553 00:19:36,280 --> 00:19:37,959 Now, when we look at the specifications 554 00:19:37,960 --> 00:19:39,189 of SSL should, too. 555 00:19:39,190 --> 00:19:41,619 We learned that there are so-called 556 00:19:41,620 --> 00:19:44,019 export ciphers that only have 557 00:19:44,020 --> 00:19:45,879 40 bits of strength. 558 00:19:45,880 --> 00:19:48,099 So this is how a cipher suite looks 559 00:19:48,100 --> 00:19:50,619 like. And it keeps on looking like this 560 00:19:50,620 --> 00:19:52,239 always has the same format. 561 00:19:52,240 --> 00:19:54,319 It tells us there's so 562 00:19:54,320 --> 00:19:57,039 the symmetric key 563 00:19:57,040 --> 00:19:59,319 algorithm that we use as RC two. 564 00:19:59,320 --> 00:20:02,139 It uses 128 bit keys. 565 00:20:02,140 --> 00:20:04,389 It uses a CBC as a 566 00:20:04,390 --> 00:20:06,249 as a mode of encryption. 567 00:20:06,250 --> 00:20:08,619 And it uses export 40 568 00:20:08,620 --> 00:20:10,719 with MDT five as hash as some hash 569 00:20:10,720 --> 00:20:11,859 algorithm. 570 00:20:11,860 --> 00:20:14,139 So that means we have 128 bit 571 00:20:14,140 --> 00:20:16,629 key, but only 40 bit of those 572 00:20:16,630 --> 00:20:18,039 are encrypted. 573 00:20:18,040 --> 00:20:20,199 I told you, the client generates 574 00:20:20,200 --> 00:20:22,629 the symmetric key and sent encrypted 575 00:20:22,630 --> 00:20:24,759 with the public key off the server and 576 00:20:24,760 --> 00:20:25,989 sends it over. 577 00:20:25,990 --> 00:20:28,569 And here it doesn't fully encrypted 578 00:20:28,570 --> 00:20:30,669 128 bit, but only the 579 00:20:30,670 --> 00:20:32,769 40 bits on 40 bits 580 00:20:32,770 --> 00:20:35,169 will be encrypted and 88 bits 581 00:20:35,170 --> 00:20:36,519 are sent in clear. 582 00:20:36,520 --> 00:20:38,649 So everyone can read it. 583 00:20:38,650 --> 00:20:40,839 And in the 90s, the Clinton 584 00:20:40,840 --> 00:20:43,329 administration did this regulation. 585 00:20:43,330 --> 00:20:45,609 They said, OK, so 40 bid is enough 586 00:20:45,610 --> 00:20:48,069 to protect like people 587 00:20:48,070 --> 00:20:50,199 with online banking stuff and 588 00:20:50,200 --> 00:20:51,200 so on and so on. 589 00:20:52,060 --> 00:20:54,339 But the obviously the US government 590 00:20:54,340 --> 00:20:56,379 wanted to look into the into the SSL 591 00:20:56,380 --> 00:20:58,649 connections of whatever country 592 00:20:58,650 --> 00:21:00,729 this this cryptographic hold will be 593 00:21:00,730 --> 00:21:01,730 exported. 594 00:21:03,060 --> 00:21:05,089 When you look at the implementation, the 595 00:21:05,090 --> 00:21:07,379 master key will be built 596 00:21:07,380 --> 00:21:09,689 in a way that the clear bits, 597 00:21:09,690 --> 00:21:11,099 the eighty-eight clear bits will be 598 00:21:11,100 --> 00:21:13,819 concatenated to the decrypted 599 00:21:13,820 --> 00:21:15,869 40 bit secret keys. 600 00:21:15,870 --> 00:21:16,919 Right. 601 00:21:16,920 --> 00:21:19,079 And obviously for nonexperts 602 00:21:19,080 --> 00:21:21,179 cyphers. So you get the same cipher suite 603 00:21:21,180 --> 00:21:23,909 without the export 40 here for nonexperts 604 00:21:23,910 --> 00:21:25,589 cyphers, the length of M.K.. 605 00:21:25,590 --> 00:21:27,899 Clear. So the bits that are sending 606 00:21:27,900 --> 00:21:29,000 clear is zero. 607 00:21:30,230 --> 00:21:31,309 OK, fair enough, right? 608 00:21:31,310 --> 00:21:33,409 OK. Maybe not the best idea to do 609 00:21:33,410 --> 00:21:34,489 something like this from. 610 00:21:34,490 --> 00:21:35,989 From a politician's viewpoint. 611 00:21:35,990 --> 00:21:37,419 But still, OK, it makes sense. 612 00:21:37,420 --> 00:21:38,839 OK. At least in the 90s. 613 00:21:40,930 --> 00:21:43,029 OK, so let's look at this 614 00:21:43,030 --> 00:21:44,019 server, verify. 615 00:21:44,020 --> 00:21:46,239 This single message that 616 00:21:46,240 --> 00:21:48,339 we get and where we 617 00:21:48,340 --> 00:21:50,889 want to know the key, 618 00:21:50,890 --> 00:21:52,389 when we look at the specifications, we 619 00:21:52,390 --> 00:21:54,699 learn that the server verify 620 00:21:54,700 --> 00:21:56,769 is nothing else than the 621 00:21:56,770 --> 00:21:58,899 client random that it 622 00:21:58,900 --> 00:21:59,889 sent us in the client. 623 00:21:59,890 --> 00:22:02,049 Hello. So we know the clear takes because 624 00:22:02,050 --> 00:22:03,999 it was sent in a clear and it was 625 00:22:04,000 --> 00:22:05,979 encrypted with a master key. 626 00:22:05,980 --> 00:22:08,049 So we know the plain text and we know 627 00:22:08,050 --> 00:22:09,759 the cipher text. 628 00:22:09,760 --> 00:22:11,799 And we also know when we negotiate this 629 00:22:11,800 --> 00:22:14,139 with an a 40 bit expert 630 00:22:14,140 --> 00:22:16,299 ciphers which which we can 631 00:22:16,300 --> 00:22:19,089 do, then only 40 of those bits 632 00:22:19,090 --> 00:22:21,519 of this masses, Masaki, are secret, 633 00:22:21,520 --> 00:22:24,119 which means we 634 00:22:24,120 --> 00:22:26,019 we can do a brute force search for the 635 00:22:26,020 --> 00:22:26,439 key. 636 00:22:26,440 --> 00:22:27,519 We know the plain text. 637 00:22:27,520 --> 00:22:28,869 We know the ciphertext. 638 00:22:28,870 --> 00:22:30,729 Then we can look for the key because 639 00:22:30,730 --> 00:22:34,199 there's only two to the 40 possibilities 640 00:22:34,200 --> 00:22:36,579 of of the key size, which takes 641 00:22:36,580 --> 00:22:38,259 on beefy hardware. 642 00:22:38,260 --> 00:22:39,969 A few seconds or a few minutes. 643 00:22:39,970 --> 00:22:41,229 Right. But you can even do it on this 644 00:22:41,230 --> 00:22:43,349 laptop. May be finished in a day or so. 645 00:22:43,350 --> 00:22:45,549 OK. So there's nothing nothing really 646 00:22:45,550 --> 00:22:47,799 nothing really critical. 647 00:22:47,800 --> 00:22:48,800 OK, 648 00:22:50,100 --> 00:22:52,659 so let me show you why this is important 649 00:22:52,660 --> 00:22:54,839 and why this forms a new 650 00:22:54,840 --> 00:22:55,840 blash in the Oracle. 651 00:22:57,040 --> 00:22:59,829 So let's assume we are 652 00:22:59,830 --> 00:23:01,909 we create a new ciphertext, a 653 00:23:01,910 --> 00:23:03,969 new encrypted prematch, a secret using 654 00:23:03,970 --> 00:23:06,429 export 40 bits and 655 00:23:06,430 --> 00:23:07,509 send it to the server. 656 00:23:07,510 --> 00:23:09,699 And we do that. We do it twice with 657 00:23:09,700 --> 00:23:10,720 the same ciphertext. 658 00:23:11,920 --> 00:23:14,649 Then we get to server, verify messages 659 00:23:14,650 --> 00:23:16,569 and we break the key that was used to 660 00:23:16,570 --> 00:23:18,309 create the server, verify messages 661 00:23:19,660 --> 00:23:21,399 in case that the Prima's secret was 662 00:23:21,400 --> 00:23:22,449 correct. 663 00:23:22,450 --> 00:23:24,559 We followed this path 664 00:23:24,560 --> 00:23:27,189 there. We proceed with a decrypted pimps 665 00:23:27,190 --> 00:23:29,109 and as we didn't change the ciphertext, 666 00:23:29,110 --> 00:23:31,299 the Prima's a secret is the same. 667 00:23:31,300 --> 00:23:32,739 So therefore the massive secret is the 668 00:23:32,740 --> 00:23:34,569 same. So therefore, right, we get we get 669 00:23:34,570 --> 00:23:37,029 the same Masaki in case 670 00:23:37,030 --> 00:23:38,889 the premises secret is invalid. 671 00:23:38,890 --> 00:23:40,959 We follow this path here, 672 00:23:40,960 --> 00:23:43,359 which means that the master keys 673 00:23:43,360 --> 00:23:45,489 for both server verifies will 674 00:23:45,490 --> 00:23:48,179 be different because it will be generate 675 00:23:48,180 --> 00:23:50,649 a new prematch. The secret is generated 676 00:23:50,650 --> 00:23:53,709 for each and every request that comes in. 677 00:23:53,710 --> 00:23:55,419 And this we could distinguish. 678 00:23:55,420 --> 00:23:57,579 Right. So this forms 679 00:23:57,580 --> 00:23:59,739 a new blash in Bohol Oracle with 680 00:23:59,740 --> 00:24:02,289 the only condition. So we don't get any. 681 00:24:02,290 --> 00:24:04,419 We don't get any error messages from from 682 00:24:04,420 --> 00:24:05,529 the server. Right. 683 00:24:05,530 --> 00:24:07,179 Everything is correctly implemented as 684 00:24:07,180 --> 00:24:08,049 any RC. 685 00:24:08,050 --> 00:24:10,119 But if we sent to 686 00:24:10,120 --> 00:24:11,120 ciphertext, 687 00:24:12,310 --> 00:24:13,310 the problem here is 688 00:24:14,380 --> 00:24:16,929 so when the server verify the key 689 00:24:16,930 --> 00:24:19,479 true to to generate the server, verify 690 00:24:19,480 --> 00:24:21,369 was the same for both messages. 691 00:24:21,370 --> 00:24:23,169 Then we know it was invalid. 692 00:24:23,170 --> 00:24:24,759 Otherwise it was it was valid. 693 00:24:27,260 --> 00:24:29,349 OK, so 694 00:24:29,350 --> 00:24:31,419 when we had this and was a much 695 00:24:31,420 --> 00:24:33,609 larger group that came up with this with 696 00:24:33,610 --> 00:24:34,809 this attack. 697 00:24:34,810 --> 00:24:36,839 So we had a practical attack as against 698 00:24:36,840 --> 00:24:38,199 SSL version two. 699 00:24:38,200 --> 00:24:40,389 And now you need to imagine, like a bunch 700 00:24:40,390 --> 00:24:42,699 of academics in their ivory 701 00:24:42,700 --> 00:24:44,719 tower, you know, like high five things. 702 00:24:44,720 --> 00:24:45,759 Yeah, we do. 703 00:24:45,760 --> 00:24:47,799 We did in you attack new cryptographic 704 00:24:47,800 --> 00:24:50,579 attack, but it has zero relevance 705 00:24:50,580 --> 00:24:52,419 by itself. We were missing each other. 706 00:24:52,420 --> 00:24:53,420 Something like this. 707 00:24:55,150 --> 00:24:56,409 So we need to look further. 708 00:24:56,410 --> 00:24:57,619 That's not sufficient. 709 00:24:57,620 --> 00:24:59,769 Okay. It's a cool it's a cool academic 710 00:24:59,770 --> 00:25:01,929 attack, but it's not relevant at all for 711 00:25:01,930 --> 00:25:02,930 for the Internet. 712 00:25:06,170 --> 00:25:08,389 So let's look at how 713 00:25:08,390 --> 00:25:10,579 people use SSL 714 00:25:10,580 --> 00:25:12,440 and tearless, how they configure it. 715 00:25:14,930 --> 00:25:17,029 When you set up a new 716 00:25:17,030 --> 00:25:19,429 server using Apache or engines 717 00:25:19,430 --> 00:25:22,009 or ISIS or whatever, 718 00:25:22,010 --> 00:25:24,289 at least to my knowledge, there is no way 719 00:25:24,290 --> 00:25:26,569 of saying if a client comes 720 00:25:26,570 --> 00:25:28,699 in and he connects using tearless 721 00:25:28,700 --> 00:25:29,700 one or. 722 00:25:30,260 --> 00:25:32,329 Then he gets Kia and the if 723 00:25:32,330 --> 00:25:34,789 when he connects with SSL 724 00:25:34,790 --> 00:25:37,189 version three, he gets a different key. 725 00:25:37,190 --> 00:25:38,779 That doesn't seem to be possible. 726 00:25:38,780 --> 00:25:41,269 So that means when you set up a system 727 00:25:41,270 --> 00:25:43,489 with a key pair, they always 728 00:25:43,490 --> 00:25:45,799 use the same key material. 729 00:25:45,800 --> 00:25:48,049 It's always the same RSA 730 00:25:48,050 --> 00:25:50,149 public key and private key pair 731 00:25:50,150 --> 00:25:52,129 that will be served independently with a 732 00:25:52,130 --> 00:25:53,539 protocol virginities. 733 00:25:53,540 --> 00:25:56,030 Okay, so that's an important insight. 734 00:25:57,140 --> 00:25:58,940 What is also very interesting is 735 00:26:00,380 --> 00:26:03,199 it a valid question would be 736 00:26:03,200 --> 00:26:05,329 will people use the same 737 00:26:05,330 --> 00:26:07,309 tearless certificates for different 738 00:26:07,310 --> 00:26:08,479 protocols? 739 00:26:08,480 --> 00:26:10,669 So are there people out there 740 00:26:10,670 --> 00:26:12,529 that buy a certificate or get a 741 00:26:12,530 --> 00:26:15,379 certificate from from let's encrypt or so 742 00:26:15,380 --> 00:26:16,629 and use it for HDP? 743 00:26:16,630 --> 00:26:18,919 S for SMP, P for I meant for Pop 744 00:26:18,920 --> 00:26:21,049 three and all the different 745 00:26:21,050 --> 00:26:23,839 other other ports 746 00:26:23,840 --> 00:26:24,940 and it 747 00:26:26,500 --> 00:26:27,859 it turns out they do. 748 00:26:27,860 --> 00:26:28,860 OK. 749 00:26:29,510 --> 00:26:31,279 Which is the problem because everyone is 750 00:26:31,280 --> 00:26:33,099 looking at the secure configuration of 751 00:26:33,100 --> 00:26:34,489 HTP s. 752 00:26:34,490 --> 00:26:36,859 So everyone is looking at actually Pierce 753 00:26:36,860 --> 00:26:38,899 and no one really is looking at the 754 00:26:38,900 --> 00:26:41,179 security of the tearless configurations 755 00:26:41,180 --> 00:26:43,509 of a map pop three as 756 00:26:43,510 --> 00:26:45,290 A.P. and and so on and so on. 757 00:26:46,700 --> 00:26:48,979 So which leads 758 00:26:48,980 --> 00:26:51,319 to the fact I said oblation perhaps 759 00:26:51,320 --> 00:26:53,449 attack works against RSA 760 00:26:53,450 --> 00:26:54,559 ciphertext. 761 00:26:54,560 --> 00:26:56,239 It's nothing written that this is 762 00:26:56,240 --> 00:26:58,519 specific to a a 763 00:26:58,520 --> 00:27:00,229 specific tearless version. 764 00:27:00,230 --> 00:27:01,940 It's a generic RSA, a 765 00:27:03,380 --> 00:27:04,669 decryption Arcam. 766 00:27:04,670 --> 00:27:05,670 Right. 767 00:27:05,930 --> 00:27:08,149 So which which means if we have 768 00:27:08,150 --> 00:27:10,279 10 systems and 769 00:27:10,280 --> 00:27:12,409 these 10 systems all share the 770 00:27:12,410 --> 00:27:14,719 same certificate and only one 771 00:27:14,720 --> 00:27:16,609 of those 10 systems is vulnerable to 772 00:27:16,610 --> 00:27:18,829 drone, then the connections to 773 00:27:18,830 --> 00:27:20,569 all 10 systems can be broken. 774 00:27:21,750 --> 00:27:23,999 Because it's a generic, it's a generic, 775 00:27:24,000 --> 00:27:26,189 a generic iris, a decryption oracle. 776 00:27:26,190 --> 00:27:27,190 So it looks like this. 777 00:27:29,450 --> 00:27:30,859 This is pretty clear, right? 778 00:27:30,860 --> 00:27:33,289 So when we have a server 779 00:27:33,290 --> 00:27:35,479 and it accepts tearless connections 780 00:27:35,480 --> 00:27:37,549 and SSL wish to connections, 781 00:27:37,550 --> 00:27:39,679 then an attacker can eavesdrop 782 00:27:39,680 --> 00:27:42,409 on this tearless connection recorded 783 00:27:42,410 --> 00:27:44,569 and use the server as oblation 784 00:27:44,570 --> 00:27:46,879 bahah oracle over SSL wooshing to 785 00:27:46,880 --> 00:27:48,139 in order to break it. 786 00:27:48,140 --> 00:27:50,689 So there we are. 787 00:27:50,690 --> 00:27:52,809 So if a system supports as this 788 00:27:52,810 --> 00:27:54,799 old version to all the Teil as 789 00:27:54,800 --> 00:27:56,929 connections that go there can be broken 790 00:27:56,930 --> 00:27:58,279 as well. That's pretty clear. 791 00:28:00,110 --> 00:28:02,479 What is new here is let's have, 792 00:28:02,480 --> 00:28:04,579 let's say we have to worship that were 793 00:28:04,580 --> 00:28:06,649 two servers and both 794 00:28:06,650 --> 00:28:08,839 use the same RSA key 795 00:28:08,840 --> 00:28:10,849 material, maybe the same certificate or 796 00:28:10,850 --> 00:28:13,039 even the same certificate actually, 797 00:28:13,040 --> 00:28:14,599 or a different certificate. 798 00:28:14,600 --> 00:28:17,269 So what we saw with 799 00:28:17,270 --> 00:28:19,130 with Heartbleed was 800 00:28:20,560 --> 00:28:22,339 at the Heartbleed attack, what 801 00:28:22,340 --> 00:28:24,559 compromised the keys? 802 00:28:24,560 --> 00:28:26,449 So using a Heartbleed occur, how to 803 00:28:26,450 --> 00:28:28,849 attack an attacker could learn 804 00:28:28,850 --> 00:28:31,189 the private key off that teller server. 805 00:28:31,190 --> 00:28:33,519 So you had to apply for a new 806 00:28:33,520 --> 00:28:34,939 a new certificate. You had to buy a new 807 00:28:34,940 --> 00:28:35,899 certificate. 808 00:28:35,900 --> 00:28:37,759 What many people did is they used the 809 00:28:37,760 --> 00:28:39,529 same ah as a key pair that was 810 00:28:39,530 --> 00:28:41,539 compromised and in a previous certificate 811 00:28:41,540 --> 00:28:42,979 and bought a new certificate with the 812 00:28:42,980 --> 00:28:45,349 same keys that was 813 00:28:45,350 --> 00:28:46,699 compromised before. 814 00:28:46,700 --> 00:28:48,539 Right. Which is not a very good idea. 815 00:28:48,540 --> 00:28:50,659 OK. So it could be it could even 816 00:28:50,660 --> 00:28:53,449 be that both use a different certificate 817 00:28:53,450 --> 00:28:55,799 but have the same RSA key here. 818 00:28:55,800 --> 00:28:57,529 Right. We saw this on the Internet as 819 00:28:57,530 --> 00:28:59,929 well. So in this case, 820 00:28:59,930 --> 00:29:02,149 let's assume this server here 821 00:29:02,150 --> 00:29:03,739 doesn't support SSL version two. 822 00:29:03,740 --> 00:29:05,960 So it's not directly vulnerable to drone. 823 00:29:07,160 --> 00:29:09,469 The attacker can still eavesdrop 824 00:29:09,470 --> 00:29:11,569 on the tearless connections that it sees 825 00:29:11,570 --> 00:29:13,729 here and breaks 826 00:29:13,730 --> 00:29:16,009 it afterwards by making SSL 827 00:29:16,010 --> 00:29:18,019 wishing to connections to this server, 828 00:29:18,020 --> 00:29:19,909 which uses the same key material and 829 00:29:19,910 --> 00:29:21,260 supports SSL wishing to. 830 00:29:22,280 --> 00:29:23,280 Right. So. 831 00:29:24,370 --> 00:29:26,569 And when we 832 00:29:26,570 --> 00:29:27,949 when we scanned the Internet, 833 00:29:29,120 --> 00:29:31,189 what what how this affects 834 00:29:31,190 --> 00:29:33,109 the amount of homes that are vulnerable 835 00:29:33,110 --> 00:29:34,009 to a drone. 836 00:29:34,010 --> 00:29:35,839 This was pretty, pretty dramatic. 837 00:29:35,840 --> 00:29:38,269 But before before we look into this, 838 00:29:38,270 --> 00:29:40,549 let me just not go through 839 00:29:40,550 --> 00:29:41,969 all the numbers that you see here. 840 00:29:41,970 --> 00:29:43,519 I just put on all the numbers that you 841 00:29:43,520 --> 00:29:45,439 see that it's really a substantial amount 842 00:29:45,440 --> 00:29:47,539 of of our as a key pair 843 00:29:48,890 --> 00:29:50,419 sharing on the Internet. 844 00:29:50,420 --> 00:29:52,549 So you have to read this table like this. 845 00:29:52,550 --> 00:29:53,449 For all the S.A. 846 00:29:53,450 --> 00:29:54,589 piece servers. 847 00:29:54,590 --> 00:29:57,259 We collected the Attila's certificates 848 00:29:57,260 --> 00:29:59,569 and then looked, where did we see 849 00:29:59,570 --> 00:30:01,699 this public key 850 00:30:01,700 --> 00:30:03,349 in maybe a different certificate or the 851 00:30:03,350 --> 00:30:05,839 same certificate on some other port. 852 00:30:05,840 --> 00:30:07,909 And there we saw, for example, from all 853 00:30:07,910 --> 00:30:09,859 the tailor certificates that we 854 00:30:09,860 --> 00:30:12,179 encountered on some TV, 855 00:30:12,180 --> 00:30:15,229 30 percent we found on a map. 856 00:30:15,230 --> 00:30:16,759 No, that's pop three. 857 00:30:16,760 --> 00:30:20,429 Twenty nine percent we found on them 858 00:30:20,430 --> 00:30:22,429 on a map and so on and so on. 859 00:30:22,430 --> 00:30:25,069 And so what is really interesting here is 860 00:30:25,070 --> 00:30:26,690 people seem to share 861 00:30:28,040 --> 00:30:30,139 a substantial amount of keys across 862 00:30:30,140 --> 00:30:32,389 protocols, which is pretty 863 00:30:32,390 --> 00:30:33,659 substantial. 864 00:30:33,660 --> 00:30:34,999 This is very interesting here. 865 00:30:35,000 --> 00:30:36,699 So when you look, for example, for HDD 866 00:30:36,700 --> 00:30:39,019 Pierce. So a lot of servers 867 00:30:39,020 --> 00:30:41,119 on actually pierce where we're 868 00:30:41,120 --> 00:30:42,120 vulnerable. 869 00:30:42,890 --> 00:30:44,989 But as I said, actually, yes, 870 00:30:44,990 --> 00:30:46,549 many people look at the configuration of 871 00:30:46,550 --> 00:30:47,809 actually Pierce. 872 00:30:47,810 --> 00:30:49,519 No one seems to care about the teal as 873 00:30:49,520 --> 00:30:51,709 configuration of s.m DP. 874 00:30:51,710 --> 00:30:53,959 It's even like this that people say 875 00:30:53,960 --> 00:30:56,029 for some T.P, if you 876 00:30:56,030 --> 00:30:58,099 can't negotiate a tearless 877 00:30:58,100 --> 00:30:59,100 connection. 878 00:31:00,590 --> 00:31:01,969 If you can't negotiate a tearless 879 00:31:01,970 --> 00:31:03,409 connection, it will fall back to 880 00:31:03,410 --> 00:31:04,999 plaintext. 881 00:31:05,000 --> 00:31:07,759 So for s.m T.P bad encryption 882 00:31:07,760 --> 00:31:09,769 that cryptography is better than 883 00:31:09,770 --> 00:31:11,319 plaintext. 884 00:31:11,320 --> 00:31:13,489 Right. But what we have here right now 885 00:31:13,490 --> 00:31:15,709 is when people have a bad 886 00:31:15,710 --> 00:31:17,899 assembly, PTL s connection 887 00:31:17,900 --> 00:31:19,979 and use the same key material for a 888 00:31:19,980 --> 00:31:22,129 cheap yes, we can break here at 889 00:31:22,130 --> 00:31:24,679 HDB s connections by exploiting 890 00:31:24,680 --> 00:31:26,569 the weaknesses in your assumptive P 891 00:31:26,570 --> 00:31:27,570 configuration. 892 00:31:28,330 --> 00:31:30,339 Which is pretty, pretty substantial. 893 00:31:30,340 --> 00:31:31,900 So when we look at the numbers, 894 00:31:33,160 --> 00:31:35,319 this in most cases it doubles. 895 00:31:35,320 --> 00:31:37,599 So we had, let's say, for a 896 00:31:37,600 --> 00:31:38,869 port. Twenty five. 897 00:31:38,870 --> 00:31:40,959 Twenty eight percent of all the 898 00:31:40,960 --> 00:31:42,879 SMP peace servers that support encryption 899 00:31:42,880 --> 00:31:44,859 on the Internet were vulnerable to drop. 900 00:31:45,880 --> 00:31:48,789 Now, when we extend this attack 901 00:31:48,790 --> 00:31:50,949 and say, okay, we have 902 00:31:50,950 --> 00:31:52,509 this system here and we want to attack 903 00:31:52,510 --> 00:31:54,729 it, the system itself is not 904 00:31:54,730 --> 00:31:56,019 vulnerable to a drone. 905 00:31:56,020 --> 00:31:58,299 But the public key is used on some other 906 00:31:58,300 --> 00:31:59,769 system, on the Internet, on a different 907 00:31:59,770 --> 00:32:00,770 port. 908 00:32:01,900 --> 00:32:03,399 We can do the attack there. 909 00:32:03,400 --> 00:32:05,709 And that obvious that this year means 910 00:32:05,710 --> 00:32:08,409 that 50 percent of all SMP servers, 911 00:32:08,410 --> 00:32:11,259 encryption wise, can can be broken 912 00:32:11,260 --> 00:32:13,779 for Port 43, for example. 913 00:32:13,780 --> 00:32:15,939 It's one third of 914 00:32:15,940 --> 00:32:18,249 all the Internet that support encryption. 915 00:32:18,250 --> 00:32:19,719 We could break tearless connections to 916 00:32:19,720 --> 00:32:22,089 these systems by exploiting some 917 00:32:22,090 --> 00:32:24,219 other system that happens to use 918 00:32:24,220 --> 00:32:26,469 the same ah as a key peer and supports 919 00:32:26,470 --> 00:32:28,159 SSL Washington. 920 00:32:28,160 --> 00:32:29,529 That's a really substantial, 921 00:32:30,910 --> 00:32:32,799 substantial effect that we encountered 922 00:32:32,800 --> 00:32:33,800 here. 923 00:32:34,090 --> 00:32:36,579 OK, so 924 00:32:36,580 --> 00:32:38,709 I said that drone itself 925 00:32:38,710 --> 00:32:40,029 is not a cheap attack. 926 00:32:40,030 --> 00:32:41,829 So it's actually quite complex. 927 00:32:41,830 --> 00:32:43,959 And we thought about how can we. 928 00:32:45,100 --> 00:32:47,559 How can how can we make efficient 929 00:32:47,560 --> 00:32:49,779 attacks for for 930 00:32:49,780 --> 00:32:52,299 drone. We need to do this like 931 00:32:52,300 --> 00:32:54,609 we need to to perform to to the 40 932 00:32:54,610 --> 00:32:55,809 exhaustive searches. 933 00:32:55,810 --> 00:32:57,989 So encryptions or descriptions. 934 00:32:57,990 --> 00:33:00,219 And we need to do this for around 1000 935 00:33:00,220 --> 00:33:01,659 Oracle crews. 936 00:33:01,660 --> 00:33:03,779 So that's a that's a lot to the 937 00:33:03,780 --> 00:33:04,869 50. 938 00:33:04,870 --> 00:33:07,539 And so we basically 939 00:33:07,540 --> 00:33:09,969 we basically took the code. 940 00:33:09,970 --> 00:33:12,519 We took some code parts of open SSL 941 00:33:12,520 --> 00:33:15,099 and did an IEF implementation 942 00:33:15,100 --> 00:33:17,259 using the RC two code and the 943 00:33:17,260 --> 00:33:19,839 ANDE five code of open SSL. 944 00:33:19,840 --> 00:33:21,519 That was the chief implementation of 945 00:33:21,520 --> 00:33:22,509 everything. 946 00:33:22,510 --> 00:33:24,519 And then we had like OK, for the full 947 00:33:24,520 --> 00:33:26,469 attack, it would take us some fact 50 948 00:33:26,470 --> 00:33:27,819 days or so. 949 00:33:27,820 --> 00:33:29,619 Which is pretty long and we wanted to be 950 00:33:29,620 --> 00:33:31,689 better. Then we asked the people 951 00:33:31,690 --> 00:33:32,859 from Hash Cat. 952 00:33:32,860 --> 00:33:33,940 So the hash kit, 953 00:33:35,710 --> 00:33:37,809 the hash cat team, one of the one of 954 00:33:37,810 --> 00:33:40,029 the offers of hash cat is also co author 955 00:33:40,030 --> 00:33:40,929 of Drone. 956 00:33:40,930 --> 00:33:42,609 And so we sent him the code and ask him, 957 00:33:42,610 --> 00:33:43,569 can you. Can you help us? 958 00:33:43,570 --> 00:33:45,639 Because it is pretty similar to password 959 00:33:45,640 --> 00:33:47,739 cracking. What we're doing right drone 960 00:33:47,740 --> 00:33:50,289 is pretty similar to to 961 00:33:50,290 --> 00:33:52,419 cryptography ys with 962 00:33:52,420 --> 00:33:53,589 password cracking. 963 00:33:53,590 --> 00:33:56,019 And then you took the code overnight and 964 00:33:56,020 --> 00:33:58,119 made something like AFACT or 30 965 00:33:58,120 --> 00:34:00,089 or so improvement to it, which is really 966 00:34:00,090 --> 00:34:01,650 like, okay. This is crazy. 967 00:34:08,280 --> 00:34:09,629 Absolutely stunning. 968 00:34:09,630 --> 00:34:11,908 Right. And so so we posted this 969 00:34:11,909 --> 00:34:14,789 on Amazon AC2 and 970 00:34:14,790 --> 00:34:17,009 and found out that for the cost of 440 971 00:34:17,010 --> 00:34:19,049 dollars, we could break one tearless 972 00:34:19,050 --> 00:34:20,729 connection in eight hours. 973 00:34:20,730 --> 00:34:22,799 So this is a pretty substantial 974 00:34:22,800 --> 00:34:23,800 improvement. 975 00:34:24,960 --> 00:34:25,948 OK, cool. 976 00:34:25,949 --> 00:34:28,379 So now we have a practical attack against 977 00:34:28,380 --> 00:34:29,999 many TLR servers. 978 00:34:30,000 --> 00:34:33,178 And this works. This is this is like the. 979 00:34:33,179 --> 00:34:34,529 This is the drone attack that works 980 00:34:34,530 --> 00:34:35,530 against every 981 00:34:37,440 --> 00:34:39,149 SSL wishing to implementation out there. 982 00:34:40,440 --> 00:34:42,569 Now we have two implementation errors in 983 00:34:42,570 --> 00:34:44,819 open SSL, which are 984 00:34:44,820 --> 00:34:46,259 interesting enough so that we have to 985 00:34:46,260 --> 00:34:48,319 show them because they make drone really, 986 00:34:48,320 --> 00:34:49,259 really easy. 987 00:34:49,260 --> 00:34:50,519 The first one we adopted 988 00:34:51,900 --> 00:34:54,178 cyphers with selection back works 989 00:34:54,179 --> 00:34:55,179 like this. 990 00:34:55,920 --> 00:34:57,989 Before we can understand this, Buck. 991 00:34:57,990 --> 00:34:59,939 We need to understand that there is when 992 00:34:59,940 --> 00:35:01,949 you when you do SSL configuration or 993 00:35:01,950 --> 00:35:03,989 tearless configuration, you always have a 994 00:35:03,990 --> 00:35:06,089 protocol version and you 995 00:35:06,090 --> 00:35:07,409 have a cipher suite. 996 00:35:07,410 --> 00:35:08,789 And with every new 997 00:35:10,500 --> 00:35:12,629 protocol version, there was a bunch 998 00:35:12,630 --> 00:35:14,579 of cipher suites released. 999 00:35:14,580 --> 00:35:16,889 Right. And so what many people 1000 00:35:16,890 --> 00:35:19,379 did is they always configure 1001 00:35:19,380 --> 00:35:20,369 their cipher suites. 1002 00:35:20,370 --> 00:35:22,709 So they said, okay, we only use this 1003 00:35:22,710 --> 00:35:24,889 secure cipher suites. 1004 00:35:24,890 --> 00:35:27,269 And and then we disable 1005 00:35:27,270 --> 00:35:29,129 the ports of here, for example, we 1006 00:35:29,130 --> 00:35:31,259 disable SSL version three in order 1007 00:35:31,260 --> 00:35:33,419 to prevent the poodle attack. 1008 00:35:33,420 --> 00:35:35,669 But SSL version two was not 1009 00:35:35,670 --> 00:35:37,469 explicitly disabled. 1010 00:35:37,470 --> 00:35:39,539 Right. Which meant the 1011 00:35:39,540 --> 00:35:41,249 open SSL behind that. 1012 00:35:41,250 --> 00:35:43,709 It would enable SSL version two. 1013 00:35:43,710 --> 00:35:45,089 But there was not all the experts. 1014 00:35:45,090 --> 00:35:46,769 Cyphers would be forbidden. 1015 00:35:46,770 --> 00:35:48,959 Right. So this cipher suite configuration 1016 00:35:48,960 --> 00:35:51,029 here would forbid export 1017 00:35:51,030 --> 00:35:53,279 40 bits of cipher 1018 00:35:53,280 --> 00:35:55,439 suites. So therefore drown shouldn't 1019 00:35:55,440 --> 00:35:56,429 work. 1020 00:35:56,430 --> 00:35:57,430 OK. 1021 00:35:58,590 --> 00:36:00,839 So how does a like SSL 1022 00:36:00,840 --> 00:36:02,999 version to do the cipher 1023 00:36:03,000 --> 00:36:04,679 suite negotiation. 1024 00:36:04,680 --> 00:36:05,680 Right. 1025 00:36:06,660 --> 00:36:08,229 It works like this in the client. 1026 00:36:08,230 --> 00:36:10,319 Hello. The client asks, 1027 00:36:10,320 --> 00:36:12,389 Hey server, do you want to talk 1028 00:36:12,390 --> 00:36:14,849 with export ciphers and the SSL 1029 00:36:14,850 --> 00:36:16,469 wishing to would respond. 1030 00:36:16,470 --> 00:36:18,719 Sorry I don't do expert ciphers. 1031 00:36:18,720 --> 00:36:20,649 Right. And then the center complaint as a 1032 00:36:20,650 --> 00:36:22,739 wishing to client would say OK, are too 1033 00:36:22,740 --> 00:36:23,729 bad. OK, bye. 1034 00:36:23,730 --> 00:36:24,899 See you next time. 1035 00:36:24,900 --> 00:36:26,549 Or maybe try another protocol version or 1036 00:36:26,550 --> 00:36:27,550 saw something like this. 1037 00:36:30,540 --> 00:36:32,159 Now, this is the relevant court 1038 00:36:33,330 --> 00:36:36,119 that will that will be used 1039 00:36:36,120 --> 00:36:38,099 afterwards after the handshake that I've 1040 00:36:38,100 --> 00:36:39,359 showed you right now. 1041 00:36:39,360 --> 00:36:41,639 So let's just assume the client wouldn't 1042 00:36:41,640 --> 00:36:42,959 say, OK, bye. 1043 00:36:42,960 --> 00:36:43,929 Sorry. 1044 00:36:43,930 --> 00:36:46,119 It's really bad that we can't talk 1045 00:36:46,120 --> 00:36:47,579 exports. 1046 00:36:47,580 --> 00:36:49,889 So if the client says afterwards, OK, I 1047 00:36:49,890 --> 00:36:50,959 want to talk. Export. 1048 00:36:50,960 --> 00:36:52,949 Anyway, let's have a look how the what 1049 00:36:52,950 --> 00:36:54,209 the court does. 1050 00:36:54,210 --> 00:36:56,309 So here we receive the 1051 00:36:56,310 --> 00:36:57,899 data from the network. 1052 00:36:57,900 --> 00:36:59,219 This is like this. 1053 00:37:01,080 --> 00:37:03,419 This is that message that contains 1054 00:37:03,420 --> 00:37:05,159 the encrypted pre message secret. 1055 00:37:05,160 --> 00:37:07,349 And that also contains the cipher 1056 00:37:07,350 --> 00:37:09,119 suite that the client just selected. 1057 00:37:10,470 --> 00:37:12,539 It will get the SSL 1058 00:37:12,540 --> 00:37:14,939 cipher suite by that chart 1059 00:37:14,940 --> 00:37:15,679 that came in. 1060 00:37:15,680 --> 00:37:17,909 So each cipher suite has one byte 1061 00:37:19,170 --> 00:37:20,399 or put it differently. 1062 00:37:20,400 --> 00:37:22,739 So there's a byte that denotes a certain 1063 00:37:22,740 --> 00:37:23,639 cipher suite. 1064 00:37:23,640 --> 00:37:25,649 And this function will just get a pointer 1065 00:37:25,650 --> 00:37:28,379 to this particular crypto code. 1066 00:37:28,380 --> 00:37:30,509 If this was not successful 1067 00:37:30,510 --> 00:37:32,850 and not successful means the 1068 00:37:34,080 --> 00:37:35,369 cipher suite was selected. 1069 00:37:35,370 --> 00:37:37,749 That is not compiled in. 1070 00:37:37,750 --> 00:37:38,639 Okay. 1071 00:37:38,640 --> 00:37:40,799 And it is compiled in. 1072 00:37:40,800 --> 00:37:43,109 It will simply be used. 1073 00:37:43,110 --> 00:37:45,269 So who sees the part that checks 1074 00:37:45,270 --> 00:37:46,270 the configuration? 1075 00:37:49,660 --> 00:37:51,939 So we haven't read and certainly found 1076 00:37:51,940 --> 00:37:53,429 it right. So it's not there. 1077 00:37:53,430 --> 00:37:55,929 Okay. So basically what happens is 1078 00:37:55,930 --> 00:37:58,269 a nonstandard, compliant SSL version, 1079 00:37:58,270 --> 00:38:00,219 too, can force that handshake. 1080 00:38:00,220 --> 00:38:02,339 So we say one to talk expert Cyprus 1081 00:38:02,340 --> 00:38:03,999 and on two experts say four. 1082 00:38:04,000 --> 00:38:05,409 Sorry, OK. 1083 00:38:05,410 --> 00:38:06,519 We go. Right. 1084 00:38:06,520 --> 00:38:07,749 OK. Let's let's talk. 1085 00:38:07,750 --> 00:38:08,919 Export 40 anyway. 1086 00:38:08,920 --> 00:38:10,389 And he would say, OK, sure, we can do 1087 00:38:10,390 --> 00:38:11,390 that. 1088 00:38:11,980 --> 00:38:12,980 Sure. 1089 00:38:20,300 --> 00:38:22,669 The story behind here is like this. 1090 00:38:22,670 --> 00:38:24,769 Nimrod did this, you 1091 00:38:24,770 --> 00:38:26,839 Sappi a very bad 1092 00:38:26,840 --> 00:38:28,899 SEPI implementation of off 1093 00:38:28,900 --> 00:38:31,029 hour of like some kind of 1094 00:38:31,030 --> 00:38:33,129 a scanner in order to to 1095 00:38:33,130 --> 00:38:35,359 look how many systems on the Internet 1096 00:38:35,360 --> 00:38:36,789 supported SSL wishing to. 1097 00:38:36,790 --> 00:38:38,709 And I did the first scan and I felt like 1098 00:38:38,710 --> 00:38:40,689 this huge amount of numbers of SSL 1099 00:38:40,690 --> 00:38:41,859 watching to scanners. 1100 00:38:41,860 --> 00:38:43,779 And then I used a different scanner that 1101 00:38:43,780 --> 00:38:45,549 just looked for SSL wishing to and I 1102 00:38:45,550 --> 00:38:47,109 would say no as a solution to it's not 1103 00:38:47,110 --> 00:38:48,359 supported. 1104 00:38:48,360 --> 00:38:49,729 And I debulked in a deep pocket and 1105 00:38:49,730 --> 00:38:51,309 doctors took us weeks. 1106 00:38:51,310 --> 00:38:52,869 And then I saw that mnemba, it was just 1107 00:38:52,870 --> 00:38:55,149 too he was simply 1108 00:38:55,150 --> 00:38:57,669 too lazy to pass this message. 1109 00:38:57,670 --> 00:38:58,839 So he would just say, hey, you want to 1110 00:38:58,840 --> 00:39:00,039 talk? Expert cyphers. 1111 00:39:00,040 --> 00:39:01,239 Yeah, yeah, yeah. 1112 00:39:01,240 --> 00:39:02,609 Let's just talk export. 1113 00:39:02,610 --> 00:39:04,299 Right. He didn't just care what they're 1114 00:39:04,300 --> 00:39:06,549 what the server was was responding. 1115 00:39:06,550 --> 00:39:07,959 And so this took us. 1116 00:39:07,960 --> 00:39:09,129 Yeah. So we were lucky. 1117 00:39:09,130 --> 00:39:10,130 Okay. 1118 00:39:10,870 --> 00:39:13,389 If we didn't have this 1119 00:39:13,390 --> 00:39:14,829 this implementation back, we probably 1120 00:39:14,830 --> 00:39:16,269 wouldn't have found many of those. 1121 00:39:16,270 --> 00:39:19,059 We wouldn't even have found this back. 1122 00:39:19,060 --> 00:39:21,159 So independent, independently of your 1123 00:39:21,160 --> 00:39:23,229 SSL configuration of 1124 00:39:23,230 --> 00:39:25,419 your cipher suite configuration, using 1125 00:39:25,420 --> 00:39:27,459 this back against open SSL, we can 1126 00:39:27,460 --> 00:39:29,629 negotiate whatever you want over SSL 1127 00:39:29,630 --> 00:39:30,669 wishing to. 1128 00:39:30,670 --> 00:39:32,739 Okay, but using a nonstandard 1129 00:39:32,740 --> 00:39:35,729 compliant SSL client. 1130 00:39:35,730 --> 00:39:36,999 Okay. So this means the server is 1131 00:39:37,000 --> 00:39:38,639 vulnerable to drought and this is even 1132 00:39:38,640 --> 00:39:40,389 though you're disabled, SSL version two 1133 00:39:40,390 --> 00:39:42,190 expert cyphers, which is cool. 1134 00:39:44,820 --> 00:39:47,249 The second one is a special drone, 1135 00:39:47,250 --> 00:39:48,959 and this is really it's really very 1136 00:39:48,960 --> 00:39:49,960 special. 1137 00:39:52,080 --> 00:39:54,479 It's also an implementation flaw. 1138 00:39:54,480 --> 00:39:55,969 It's not a it's not a Ertz. 1139 00:39:55,970 --> 00:39:57,059 It's an implementation flaw. 1140 00:39:57,060 --> 00:39:59,429 So let's again use this cipher suite. 1141 00:39:59,430 --> 00:40:01,559 So we use RC to with 128 1142 00:40:01,560 --> 00:40:04,019 bit keys, but we transfer 1143 00:40:04,020 --> 00:40:05,729 all except the 40 bits and clear. 1144 00:40:05,730 --> 00:40:07,469 We have talked about this before. 1145 00:40:07,470 --> 00:40:08,539 Right. 1146 00:40:08,540 --> 00:40:11,129 An implementation flaw allowed 1147 00:40:11,130 --> 00:40:12,869 to use these clear bits. 1148 00:40:12,870 --> 00:40:15,119 So the bits that are sent in clear 1149 00:40:15,120 --> 00:40:17,909 with non export ciphers. 1150 00:40:17,910 --> 00:40:20,229 So for nonexperts cyphers, we said 1151 00:40:20,230 --> 00:40:21,739 M.K. Clear needs to be zero. 1152 00:40:22,900 --> 00:40:24,219 This is not the case here. 1153 00:40:24,220 --> 00:40:26,679 So a standard conforming 1154 00:40:26,680 --> 00:40:28,329 client would 1155 00:40:29,590 --> 00:40:30,590 like. 1156 00:40:31,700 --> 00:40:33,909 Right. So for nonexperts effort that 1157 00:40:33,910 --> 00:40:36,729 we have here, we would use all the 16 1158 00:40:36,730 --> 00:40:37,719 bytes. 1159 00:40:37,720 --> 00:40:39,329 So the hundred one hundred and twenty 1160 00:40:39,330 --> 00:40:41,409 eight bits would be filled 1161 00:40:41,410 --> 00:40:43,539 with the secret parts that we 1162 00:40:43,540 --> 00:40:45,789 just extracted from this render fun from 1163 00:40:45,790 --> 00:40:47,389 this encrypted pre massive secret. 1164 00:40:47,390 --> 00:40:48,459 OK. 1165 00:40:48,460 --> 00:40:50,709 If we sent four clear 1166 00:40:50,710 --> 00:40:52,989 bites along 1167 00:40:52,990 --> 00:40:55,239 with a 16 by prematch, the secret 1168 00:40:55,240 --> 00:40:57,549 that was encrypted, it will still 1169 00:40:57,550 --> 00:40:59,349 pre pended to the actual encrypted 1170 00:40:59,350 --> 00:41:00,549 prematch. The secret. 1171 00:41:00,550 --> 00:41:02,789 So that means K 13, k 1172 00:41:02,790 --> 00:41:04,959 fourteen fifteen would simply 1173 00:41:04,960 --> 00:41:06,269 fall off. 1174 00:41:06,270 --> 00:41:08,799 Okay. Which becomes really interesting 1175 00:41:08,800 --> 00:41:10,869 when we sent fifteen clear bites 1176 00:41:12,910 --> 00:41:15,499 because then all of a sudden we, 1177 00:41:15,500 --> 00:41:17,619 we have a server verify that was 1178 00:41:17,620 --> 00:41:19,809 encrypted with a 128 bit 1179 00:41:19,810 --> 00:41:21,190 key where we know 1180 00:41:22,540 --> 00:41:24,609 all but one byte and then we 1181 00:41:24,610 --> 00:41:26,109 can brute force on average. 1182 00:41:26,110 --> 00:41:28,239 One hundred and twenty eight encryptions. 1183 00:41:28,240 --> 00:41:29,229 Right. 1184 00:41:29,230 --> 00:41:31,569 So and now we do this like 1185 00:41:31,570 --> 00:41:34,119 in a in, in, in a stepping mode. 1186 00:41:34,120 --> 00:41:36,249 Right. So we 1187 00:41:36,250 --> 00:41:38,589 we sent fifteen zero bytes as MKC 1188 00:41:38,590 --> 00:41:40,899 clear. We break this ciphertext. 1189 00:41:40,900 --> 00:41:42,969 We learned K one in a second step. 1190 00:41:42,970 --> 00:41:45,789 We sent 14 zero bytes. 1191 00:41:45,790 --> 00:41:47,919 We know K one from the previous step. 1192 00:41:47,920 --> 00:41:49,289 So we brute force K two 1193 00:41:50,440 --> 00:41:52,929 in the next step. We sent 13 1194 00:41:52,930 --> 00:41:54,789 zero bytes. We know K one. 1195 00:41:54,790 --> 00:41:56,259 We know K two. 1196 00:41:56,260 --> 00:41:57,639 We want to brute force K three. 1197 00:41:57,640 --> 00:41:59,469 And we do it right. 1198 00:41:59,470 --> 00:42:01,659 And then like 1199 00:42:01,660 --> 00:42:03,729 for this case where we send 1200 00:42:03,730 --> 00:42:06,069 zero zero bytes, 1201 00:42:06,070 --> 00:42:08,559 we have learned K one to K 15 1202 00:42:08,560 --> 00:42:10,089 and only have one byte and we need to 1203 00:42:10,090 --> 00:42:11,009 brute force it. 1204 00:42:11,010 --> 00:42:12,989 It's again, 128 bit. 1205 00:42:12,990 --> 00:42:13,990 Right. OK. 1206 00:42:15,310 --> 00:42:16,359 So that means. 1207 00:42:16,360 --> 00:42:19,169 So we tap this special round because it's 1208 00:42:19,170 --> 00:42:21,159 a special, a special version of this 1209 00:42:21,160 --> 00:42:23,229 attack. The generic drawn stealer has to 1210 00:42:23,230 --> 00:42:25,419 to the 40 complexity per 1211 00:42:25,420 --> 00:42:26,749 Oracle request. 1212 00:42:26,750 --> 00:42:28,719 And we need to have something like 1000 1213 00:42:28,720 --> 00:42:29,769 Oracle requests. 1214 00:42:29,770 --> 00:42:31,239 That's pretty substantial. 1215 00:42:31,240 --> 00:42:32,949 But this, too, to the 40 in case of 1216 00:42:32,950 --> 00:42:35,019 special drone goes down 1217 00:42:35,020 --> 00:42:37,429 to 50 probe connections and 1218 00:42:37,430 --> 00:42:39,609 altogether approximately less than 1219 00:42:39,610 --> 00:42:41,859 two thousand encrypted encryptions, 1220 00:42:41,860 --> 00:42:43,989 encryptions that this can be done 1221 00:42:43,990 --> 00:42:45,639 with. The full attack can be done within 1222 00:42:45,640 --> 00:42:47,979 a few minutes 1223 00:42:47,980 --> 00:42:50,079 on on just a normal Linux 1224 00:42:50,080 --> 00:42:51,309 laptop. Right. 1225 00:42:51,310 --> 00:42:52,900 Which is very, very critical. 1226 00:42:54,610 --> 00:42:56,679 So what is interesting here is 1227 00:42:56,680 --> 00:42:59,589 this spark has been fixed 1228 00:42:59,590 --> 00:43:01,989 by an openness, this developer, 1229 00:43:01,990 --> 00:43:03,479 without knowing that it was fixed. 1230 00:43:03,480 --> 00:43:05,319 So Nimrod and I, we submitted a buck that 1231 00:43:05,320 --> 00:43:06,879 was totally unrelated to Drom. 1232 00:43:06,880 --> 00:43:09,219 We didn't even know Dromm dislike 1233 00:43:09,220 --> 00:43:11,439 one and four years ago or so and openness 1234 00:43:11,440 --> 00:43:13,539 as L did a patch and 1235 00:43:13,540 --> 00:43:15,519 they patched this back without knowing 1236 00:43:15,520 --> 00:43:16,709 what it what it actually was. 1237 00:43:16,710 --> 00:43:18,939 So it wasn't really a silent fix because 1238 00:43:18,940 --> 00:43:21,129 no one was really noticing 1239 00:43:21,130 --> 00:43:22,569 what was going on here. 1240 00:43:22,570 --> 00:43:24,729 But later, later we figured out 1241 00:43:24,730 --> 00:43:25,779 that it's that this is pretty 1242 00:43:25,780 --> 00:43:27,069 substantial. 1243 00:43:27,070 --> 00:43:29,679 Why I'm explaining this to you is 1244 00:43:29,680 --> 00:43:31,899 we can scan we can scan again 1245 00:43:31,900 --> 00:43:33,999 the Internet for this and 1246 00:43:34,000 --> 00:43:36,549 we can look at who didn't 1247 00:43:36,550 --> 00:43:37,689 patch. 1248 00:43:37,690 --> 00:43:39,909 They are open SSL. 1249 00:43:39,910 --> 00:43:42,069 When we submitted the patch like one 1250 00:43:42,070 --> 00:43:43,299 and a half years before. 1251 00:43:43,300 --> 00:43:45,849 Right. And so this here means 1252 00:43:45,850 --> 00:43:46,850 this is like the. 1253 00:43:48,130 --> 00:43:50,919 This is the amount of Internet hosts 1254 00:43:50,920 --> 00:43:52,630 that run some kind of 1255 00:43:53,740 --> 00:43:55,929 some kind of encryption and that use 1256 00:43:55,930 --> 00:43:58,119 SS open SSL that is more than one 1257 00:43:58,120 --> 00:43:59,289 year old. 1258 00:43:59,290 --> 00:44:01,599 So these people don't really patch. 1259 00:44:01,600 --> 00:44:03,999 And when you when you go 1260 00:44:04,000 --> 00:44:06,189 when you compare this to the two to 1261 00:44:06,190 --> 00:44:07,869 the amount of service that are vulnerable 1262 00:44:07,870 --> 00:44:10,059 to drone, you will see that most of them 1263 00:44:10,060 --> 00:44:12,729 are open SSL actually, because 1264 00:44:12,730 --> 00:44:13,810 the numbers are very similar. 1265 00:44:15,270 --> 00:44:16,329 Okay. 1266 00:44:16,330 --> 00:44:18,009 So in summary, that's just one sentence 1267 00:44:18,010 --> 00:44:19,239 that I can say here. 1268 00:44:19,240 --> 00:44:21,429 Ancient SSL Bushin to breaks 1269 00:44:21,430 --> 00:44:23,799 current tearless and we can do nothing 1270 00:44:23,800 --> 00:44:26,109 else than than just disabling 1271 00:44:26,110 --> 00:44:27,029 SSL Bushin tool. 1272 00:44:27,030 --> 00:44:28,749 Right. It's dead forgood. 1273 00:44:28,750 --> 00:44:30,819 But an important discussion 1274 00:44:30,820 --> 00:44:33,189 is also what's also who's to blame 1275 00:44:33,190 --> 00:44:35,209 for, for drone. 1276 00:44:35,210 --> 00:44:37,199 So what was the fault here. 1277 00:44:37,200 --> 00:44:39,339 So for the first one is is pretty 1278 00:44:39,340 --> 00:44:41,319 obvious. So we have some crypto design 1279 00:44:41,320 --> 00:44:43,949 flaws were done in the 90s. 1280 00:44:43,950 --> 00:44:44,979 OK. That's nothing. 1281 00:44:44,980 --> 00:44:46,239 That is really too surprising. 1282 00:44:46,240 --> 00:44:47,309 OK. Right. 1283 00:44:47,310 --> 00:44:49,239 Twenty years ago, many things happened 1284 00:44:49,240 --> 00:44:50,240 between them. 1285 00:44:51,340 --> 00:44:53,289 We have some crypto implementation flaws 1286 00:44:53,290 --> 00:44:55,479 from the 90s. And like the openness, SSL 1287 00:44:55,480 --> 00:44:57,159 guys were like, okay, I've never looked 1288 00:44:57,160 --> 00:44:59,499 at has the SSL version too cold. 1289 00:44:59,500 --> 00:45:00,819 It's been there forever. 1290 00:45:00,820 --> 00:45:01,839 Nobody has looked at it. 1291 00:45:01,840 --> 00:45:03,819 And so it's really old implementation 1292 00:45:03,820 --> 00:45:04,820 code. 1293 00:45:05,830 --> 00:45:08,109 What is more a problem is the crypto 1294 00:45:08,110 --> 00:45:09,189 configuration Flosse. 1295 00:45:09,190 --> 00:45:11,279 So people where where we're 1296 00:45:11,280 --> 00:45:13,689 configuring their their SSL 1297 00:45:13,690 --> 00:45:16,029 servers in a in a pretty bad May. 1298 00:45:16,030 --> 00:45:18,339 And what is also quite interesting 1299 00:45:18,340 --> 00:45:20,769 is the export 1300 00:45:20,770 --> 00:45:21,979 export cyphers export. 1301 00:45:21,980 --> 00:45:24,149 Forty bits is a thing is an is 1302 00:45:24,150 --> 00:45:26,459 an essential part to drones, 1303 00:45:26,460 --> 00:45:28,769 so drone wouldn't be a practical attack 1304 00:45:28,770 --> 00:45:29,939 if we hadn't. 1305 00:45:29,940 --> 00:45:32,069 The Clinton administration who forced 1306 00:45:32,070 --> 00:45:34,319 this crypto regulation that only 1307 00:45:34,320 --> 00:45:36,419 exports expert cryptography may 1308 00:45:36,420 --> 00:45:38,789 only have like 40 bits in secret. 1309 00:45:40,920 --> 00:45:43,189 OK, so what are the mitigations 1310 00:45:43,190 --> 00:45:44,929 for for the administrators here? 1311 00:45:44,930 --> 00:45:47,019 So this able SSL version two 1312 00:45:47,020 --> 00:45:49,099 and SSL version three while you're at it. 1313 00:45:49,100 --> 00:45:50,059 Right. Because it's also. 1314 00:45:50,060 --> 00:45:51,699 So SSL is insecure, right. 1315 00:45:51,700 --> 00:45:53,649 Don't use the word SSL anymore. 1316 00:45:53,650 --> 00:45:54,999 Telesis, the real thing. 1317 00:45:55,000 --> 00:45:57,079 Okay. And then obviously update, 1318 00:45:57,080 --> 00:45:59,149 update here, open SSL regularly, 1319 00:45:59,150 --> 00:46:00,529 which is a thing that you should do for 1320 00:46:00,530 --> 00:46:03,199 every library that is in some kind of 1321 00:46:03,200 --> 00:46:04,489 security relevant. 1322 00:46:04,490 --> 00:46:05,490 Okay. 1323 00:46:05,900 --> 00:46:07,459 So this is the mitigation for the Atman. 1324 00:46:07,460 --> 00:46:09,139 The mitigation for the citizen, in my 1325 00:46:09,140 --> 00:46:11,629 opinion, is vote against crypto vectors. 1326 00:46:11,630 --> 00:46:12,630 Right. 1327 00:46:13,040 --> 00:46:14,040 Thank you so much. 1328 00:46:31,060 --> 00:46:32,649 Thank you, Sebastian. 1329 00:46:32,650 --> 00:46:34,869 Do we have questions from 1330 00:46:34,870 --> 00:46:36,149 the audience? 1331 00:46:36,150 --> 00:46:38,649 OK, well, one question, I think 1332 00:46:38,650 --> 00:46:41,149 we started with microphone three, please. 1333 00:46:41,150 --> 00:46:43,299 Yeah, actually, two questions. 1334 00:46:43,300 --> 00:46:45,489 One is how specific this is for 1335 00:46:45,490 --> 00:46:47,019 RSA. 1336 00:46:47,020 --> 00:46:48,969 I mean, would it work also for deeply 1337 00:46:48,970 --> 00:46:51,189 held lambaste crypto? 1338 00:46:51,190 --> 00:46:53,419 And also, after they had 1339 00:46:53,420 --> 00:46:55,539 Heartbleed, a lot of people start 1340 00:46:55,540 --> 00:46:58,299 looking into the openness, a so-called an 1341 00:46:58,300 --> 00:47:00,309 even forum started and so on. 1342 00:47:00,310 --> 00:47:02,589 So has the situation improved 1343 00:47:02,590 --> 00:47:03,590 since then? 1344 00:47:04,240 --> 00:47:06,429 So the first question was, is it is 1345 00:47:06,430 --> 00:47:08,499 it limited to RSA? 1346 00:47:08,500 --> 00:47:10,389 Yes, it is somehow. 1347 00:47:10,390 --> 00:47:12,729 We can we can impersonate 1348 00:47:12,730 --> 00:47:14,979 the server with 1349 00:47:14,980 --> 00:47:16,959 like when we have substantial hardware, 1350 00:47:16,960 --> 00:47:19,259 we can impersonate the server 1351 00:47:19,260 --> 00:47:20,599 simply. 1352 00:47:20,600 --> 00:47:22,809 Well, it's hard to explain 1353 00:47:22,810 --> 00:47:25,209 like this without ah, 1354 00:47:25,210 --> 00:47:27,729 like without sleights for this. 1355 00:47:27,730 --> 00:47:29,739 So, so, so look at the paper. 1356 00:47:29,740 --> 00:47:32,349 So we have broken quick using this. 1357 00:47:32,350 --> 00:47:33,759 We can break it if he hulman. 1358 00:47:33,760 --> 00:47:34,659 But this needs to. 1359 00:47:34,660 --> 00:47:35,919 This is not an off-line attack. 1360 00:47:35,920 --> 00:47:37,509 It needs to be an active men in the 1361 00:47:37,510 --> 00:47:39,639 middle. Okay, so your first 1362 00:47:39,640 --> 00:47:41,959 question and it's limited to RSA. 1363 00:47:41,960 --> 00:47:43,269 Yeah. So. 1364 00:47:43,270 --> 00:47:44,270 So for example. 1365 00:47:45,670 --> 00:47:47,229 Yeah. So difficult and doesn't work. 1366 00:47:47,230 --> 00:47:48,219 And your second question was. 1367 00:47:48,220 --> 00:47:49,149 Excuse me. 1368 00:47:49,150 --> 00:47:51,429 If the situation is open, SSL 1369 00:47:51,430 --> 00:47:53,229 or other assali implementations has 1370 00:47:53,230 --> 00:47:54,919 improved since Heartbleed. 1371 00:47:54,920 --> 00:47:57,219 Okay. So this back hasn't popped up 1372 00:47:57,220 --> 00:47:58,689 in one of the audits. 1373 00:47:58,690 --> 00:48:00,549 Probably because people didn't care about 1374 00:48:00,550 --> 00:48:02,289 SSL wishing to because it's already 1375 00:48:02,290 --> 00:48:03,639 messed up. Right. 1376 00:48:03,640 --> 00:48:05,709 So people were doing a focused audit, 1377 00:48:05,710 --> 00:48:06,939 which is what I would expect. 1378 00:48:06,940 --> 00:48:07,949 They did a good job there. 1379 00:48:11,230 --> 00:48:12,939 OK. Thank you. 1380 00:48:12,940 --> 00:48:15,219 Do we have questions from the Internet? 1381 00:48:15,220 --> 00:48:16,329 No. OK. 1382 00:48:16,330 --> 00:48:18,069 Microphone one, please. 1383 00:48:18,070 --> 00:48:19,659 More of a note. 1384 00:48:19,660 --> 00:48:21,559 When you say you have to update or open a 1385 00:48:21,560 --> 00:48:23,109 cell regularly. 1386 00:48:23,110 --> 00:48:24,399 Something that's important is that you 1387 00:48:24,400 --> 00:48:25,929 actually restart all your services 1388 00:48:25,930 --> 00:48:27,409 because if you just update your old 1389 00:48:27,410 --> 00:48:29,799 message, cell implementation, all the 1390 00:48:29,800 --> 00:48:31,569 running processes are still linked 1391 00:48:31,570 --> 00:48:32,779 against the old version. 1392 00:48:32,780 --> 00:48:34,539 That's a deleted file. 1393 00:48:34,540 --> 00:48:36,009 And you're still vulnerable unless you 1394 00:48:36,010 --> 00:48:37,569 actually restart every single one of your 1395 00:48:37,570 --> 00:48:40,209 services that links against openness SSL. 1396 00:48:40,210 --> 00:48:41,859 But there goes your uptime, right? 1397 00:48:41,860 --> 00:48:43,889 1000 days uptime. 1398 00:48:43,890 --> 00:48:44,829 Yeah. 1399 00:48:44,830 --> 00:48:46,510 Thank you. Microphone four, please. 1400 00:48:48,550 --> 00:48:50,919 You mentioned that there's a factor 1401 00:48:50,920 --> 00:48:53,129 of 1000 that you have to apply to the 1402 00:48:53,130 --> 00:48:55,390 twenty two to the four touch of the 40. 1403 00:48:56,650 --> 00:48:58,039 Where does that come from? 1404 00:48:58,040 --> 00:48:59,199 I think I missed it. 1405 00:48:59,200 --> 00:49:02,139 It comes from an algorithm. 1406 00:49:02,140 --> 00:49:03,979 Right. So it's when blind. 1407 00:49:03,980 --> 00:49:05,829 But has the algorithm from 1998 was 1408 00:49:05,830 --> 00:49:07,599 published? It was dubbed the Million 1409 00:49:07,600 --> 00:49:09,849 Questions Attack because you used 1410 00:49:09,850 --> 00:49:12,099 to have to send like one million 1411 00:49:12,100 --> 00:49:14,619 on average one million messages between 1412 00:49:14,620 --> 00:49:16,899 client and server in order to 1413 00:49:16,900 --> 00:49:19,329 to decrypt the ciphertext. 1414 00:49:21,220 --> 00:49:23,509 This has changed dramatically in 1415 00:49:23,510 --> 00:49:24,909 the years between. So there are several 1416 00:49:24,910 --> 00:49:27,069 papers that it improvements to 1417 00:49:27,070 --> 00:49:28,569 the to the attack. 1418 00:49:28,570 --> 00:49:30,239 And now it's boiling down to two. 1419 00:49:30,240 --> 00:49:31,779 A thousand approximately. 1420 00:49:31,780 --> 00:49:32,829 It depends on the size. 1421 00:49:32,830 --> 00:49:34,359 It depends on a pre massive secret. 1422 00:49:34,360 --> 00:49:36,429 But on average, 1000 1423 00:49:36,430 --> 00:49:37,659 connections is what we need. 1424 00:49:38,890 --> 00:49:39,890 OK. 1425 00:49:40,760 --> 00:49:42,499 Thank you. And the next question is on 1426 00:49:42,500 --> 00:49:43,859 microphone one, please. 1427 00:49:43,860 --> 00:49:46,249 Hi. This is just a paranoid question 1428 00:49:46,250 --> 00:49:47,869 about if you're using the open SSL 1429 00:49:47,870 --> 00:49:50,539 library when you said 1430 00:49:50,540 --> 00:49:52,519 disable the protocols. 1431 00:49:52,520 --> 00:49:54,259 I presume that means when you do the 1432 00:49:54,260 --> 00:49:56,339 function, call where you pass in no 1433 00:49:56,340 --> 00:49:58,519 tearless version or no SSL 1434 00:49:58,520 --> 00:50:00,169 version, there's no asset. 1435 00:50:00,170 --> 00:50:01,099 Has someone checked that? 1436 00:50:01,100 --> 00:50:02,569 They're actually checking that if they're 1437 00:50:02,570 --> 00:50:04,519 not checking the protocol, sir. 1438 00:50:04,520 --> 00:50:05,749 If they're not checking the cipher 1439 00:50:05,750 --> 00:50:06,750 suites, rather. 1440 00:50:08,180 --> 00:50:10,189 Are we guaranteed that doing that means 1441 00:50:10,190 --> 00:50:13,609 you're protected? Can I if if I've 1442 00:50:13,610 --> 00:50:15,919 if I've said no SSL 1443 00:50:15,920 --> 00:50:17,809 V2 when I pass it, when I 1444 00:50:18,920 --> 00:50:21,079 set up the context in 1445 00:50:21,080 --> 00:50:23,209 the library, does that mean I can 1446 00:50:23,210 --> 00:50:25,459 breezy breathe easy. 1447 00:50:25,460 --> 00:50:27,799 So open SSL deleted the SSL version 1448 00:50:27,800 --> 00:50:30,199 to code after we did the 1449 00:50:30,200 --> 00:50:32,569 OK, we told them to try and just 1450 00:50:32,570 --> 00:50:34,669 update open SSL and you'll be fine. 1451 00:50:34,670 --> 00:50:35,689 It will be deleted. 1452 00:50:35,690 --> 00:50:37,189 It's not there in the repository and 1453 00:50:37,190 --> 00:50:38,959 that's what I wanted to hear. 1454 00:50:38,960 --> 00:50:39,960 And restart your server. 1455 00:50:41,190 --> 00:50:42,440 You're sorry. Service. 1456 00:50:45,500 --> 00:50:48,259 Microphone five five in the back, please. 1457 00:50:48,260 --> 00:50:49,939 Yes. Thank you. 1458 00:50:49,940 --> 00:50:52,219 I wanted to ask, 1459 00:50:52,220 --> 00:50:54,619 have you looked into a other 1460 00:50:54,620 --> 00:50:56,119 group, the Cloudberries? 1461 00:50:56,120 --> 00:50:58,009 Except SSL? 1462 00:50:58,010 --> 00:51:00,559 Yeah. So most of the modern 1463 00:51:00,560 --> 00:51:02,749 crypto libraries, some with 1464 00:51:02,750 --> 00:51:04,789 modern. I mean, the ones that appeared in 1465 00:51:04,790 --> 00:51:07,159 the last few years, they didn't implement 1466 00:51:07,160 --> 00:51:09,229 SSL version two at all anymore. 1467 00:51:09,230 --> 00:51:11,149 So Lieber SSL, for example, they just 1468 00:51:11,150 --> 00:51:12,619 deleted the code. 1469 00:51:12,620 --> 00:51:14,929 Boring SSL deleted the code 1470 00:51:14,930 --> 00:51:16,429 like the Python libraries and so they 1471 00:51:16,430 --> 00:51:18,589 didn't even implemented and so on and so 1472 00:51:18,590 --> 00:51:19,039 on. 1473 00:51:19,040 --> 00:51:21,289 But all the ones that were 1474 00:51:21,290 --> 00:51:23,269 that we looked at, for example, the code 1475 00:51:23,270 --> 00:51:25,160 that is in ISIS s channel, 1476 00:51:26,270 --> 00:51:28,639 it has it still supports SSL 1477 00:51:28,640 --> 00:51:31,279 version two and it has the same 1478 00:51:31,280 --> 00:51:32,479 the same protocols loss. 1479 00:51:32,480 --> 00:51:34,579 So if you support SSL 1480 00:51:34,580 --> 00:51:36,649 version two, you are vulnerable. 1481 00:51:36,650 --> 00:51:38,419 Independently of of of the 1482 00:51:38,420 --> 00:51:40,099 implementation, at least how we looked at 1483 00:51:40,100 --> 00:51:41,239 it. 1484 00:51:41,240 --> 00:51:42,629 Okay. Thank you. 1485 00:51:42,630 --> 00:51:44,539 Welcome. And I think microphone one, 1486 00:51:44,540 --> 00:51:46,500 please. Why the name drown? 1487 00:51:50,660 --> 00:51:52,189 That's a good question. So there's. 1488 00:51:52,190 --> 00:51:53,659 I think so. 1489 00:51:53,660 --> 00:51:55,189 So, Nima, what came up with the initial 1490 00:51:55,190 --> 00:51:57,259 idea and he has this like his favorite 1491 00:51:57,260 --> 00:51:59,419 movie where this plays a role. 1492 00:51:59,420 --> 00:52:01,379 And then we did a backroom, which which 1493 00:52:01,380 --> 00:52:03,319 which I don't remember anymore. 1494 00:52:03,320 --> 00:52:04,399 It's written in the paper. 1495 00:52:04,400 --> 00:52:06,499 Sorry about it. I don't even know 1496 00:52:06,500 --> 00:52:08,209 that the background of many anymore. 1497 00:52:08,210 --> 00:52:09,289 It's just a working name. 1498 00:52:09,290 --> 00:52:11,609 And then it got like viral and. 1499 00:52:11,610 --> 00:52:12,610 Yeah. 1500 00:52:14,580 --> 00:52:16,019 And, of course, then for more information 1501 00:52:16,020 --> 00:52:17,250 is provided under our plan. 1502 00:52:18,540 --> 00:52:20,210 So any other questions? 1503 00:52:23,690 --> 00:52:25,819 OK, in this case, I have 1504 00:52:25,820 --> 00:52:26,820 a question. 1505 00:52:27,680 --> 00:52:29,949 Usually you say, OK, 1506 00:52:29,950 --> 00:52:32,359 the which which politician 1507 00:52:32,360 --> 00:52:34,459 was it that said, OK, please, we can 1508 00:52:34,460 --> 00:52:36,989 the strength, the bladder security 1509 00:52:36,990 --> 00:52:39,649 that we veto security. 1510 00:52:39,650 --> 00:52:41,499 I'm sorry, I don't get the audio. 1511 00:52:41,500 --> 00:52:42,949 Oh, yeah. Of course, the audio under 1512 00:52:42,950 --> 00:52:43,950 stage is not that good. 1513 00:52:45,920 --> 00:52:46,909 Let's say more. 1514 00:52:46,910 --> 00:52:48,979 And in general information, um, 1515 00:52:48,980 --> 00:52:50,659 we have the politicians that try to 1516 00:52:50,660 --> 00:52:52,489 weaken the security. 1517 00:52:52,490 --> 00:52:54,149 So which one was it again? 1518 00:52:54,150 --> 00:52:55,819 And this was the Clinton deklin. 1519 00:52:55,820 --> 00:52:57,229 OK. This is not true. 1520 00:52:57,230 --> 00:52:58,819 I mean, every every politician obviously 1521 00:52:58,820 --> 00:53:00,289 wants to wants to do this because of 1522 00:53:00,290 --> 00:53:01,849 terrorism. Yes, of course. 1523 00:53:01,850 --> 00:53:04,189 Know. Because you're all that bad people. 1524 00:53:04,190 --> 00:53:06,169 Yeah. And so if we do this right now, if 1525 00:53:06,170 --> 00:53:07,909 you have Krypto regulations right now, we 1526 00:53:07,910 --> 00:53:09,859 at least make sure that maybe in 10 1527 00:53:09,860 --> 00:53:11,629 years, maybe five years, maybe maybe 1528 00:53:11,630 --> 00:53:13,909 fifteen years, we have another bunch of 1529 00:53:13,910 --> 00:53:16,369 crypto students who can write their 1530 00:53:16,370 --> 00:53:18,459 thesis on it, how to break them. 1531 00:53:18,460 --> 00:53:20,509 I'd say it's maybe one good thing about 1532 00:53:20,510 --> 00:53:22,189 it, but it's and generally it's not a 1533 00:53:22,190 --> 00:53:23,190 good idea. 1534 00:53:23,870 --> 00:53:24,870 OK. 1535 00:53:25,640 --> 00:53:28,009 Any other questions in the meantime? 1536 00:53:28,010 --> 00:53:30,169 I think microphone five is. 1537 00:53:30,170 --> 00:53:31,759 Is this a question? 1538 00:53:31,760 --> 00:53:33,139 No, this is just down. 1539 00:53:37,090 --> 00:53:38,090 There is a question. 1540 00:53:40,570 --> 00:53:41,570 For please. 1541 00:53:42,330 --> 00:53:44,669 You said that four were 1542 00:53:44,670 --> 00:53:46,799 from maidservants, it's still 1543 00:53:46,800 --> 00:53:49,149 a good idea to sop support or crypto, 1544 00:53:49,150 --> 00:53:51,419 so with a drone attack, it isn't anymore, 1545 00:53:51,420 --> 00:53:52,439 I expect. 1546 00:53:52,440 --> 00:53:55,079 Or did I misunderstand? 1547 00:53:55,080 --> 00:53:57,449 So there's an argument of supporting SSL 1548 00:53:57,450 --> 00:53:59,729 version three, even though it's broken, 1549 00:53:59,730 --> 00:54:01,769 but it's broken in a sense. 1550 00:54:01,770 --> 00:54:04,189 So the poodle attack is still 1551 00:54:04,190 --> 00:54:06,869 it's it's obviously more effort 1552 00:54:06,870 --> 00:54:09,239 breaking SSL version three than 1553 00:54:09,240 --> 00:54:10,679 reading the plain text. 1554 00:54:10,680 --> 00:54:13,019 Okay. With the drone attack, it's 1555 00:54:13,020 --> 00:54:15,209 different because even 1556 00:54:15,210 --> 00:54:17,849 when you use security, less connections, 1557 00:54:17,850 --> 00:54:20,039 you can still break it by exploiting SSL 1558 00:54:20,040 --> 00:54:21,219 version two. 1559 00:54:21,220 --> 00:54:23,369 So and third, the word 1560 00:54:23,370 --> 00:54:25,499 for this is opportunistic encryption. 1561 00:54:25,500 --> 00:54:27,719 So some bad encryption is even better 1562 00:54:27,720 --> 00:54:29,009 than no encryption. 1563 00:54:29,010 --> 00:54:30,869 And this change for drone and I think 1564 00:54:30,870 --> 00:54:32,669 this is the first attack where where this 1565 00:54:32,670 --> 00:54:34,049 works cross protocol. 1566 00:54:34,050 --> 00:54:36,749 But don't you compromise? 1567 00:54:36,750 --> 00:54:38,209 Oh, yeah. And you don't compromise. 1568 00:54:38,210 --> 00:54:40,369 You are as a private key battleground. 1569 00:54:40,370 --> 00:54:41,439 Okay. Yeah, then I get it. 1570 00:54:41,440 --> 00:54:43,179 So you don't need to buy a new piece for 1571 00:54:43,180 --> 00:54:44,909 it. Right. You can still use your same 1572 00:54:44,910 --> 00:54:47,219 key. Just just 1573 00:54:47,220 --> 00:54:49,079 remove SSL version two from your 1574 00:54:49,080 --> 00:54:51,359 configuration and restart the server 1575 00:54:51,360 --> 00:54:53,699 in your file or update open SSL. 1576 00:54:55,780 --> 00:54:56,780 OK. 1577 00:54:57,380 --> 00:54:58,380 Any other questions? 1578 00:55:01,040 --> 00:55:03,619 In this case, please give an anniversary 1579 00:55:03,620 --> 00:55:05,630 edition applause to us by sentients or.